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ON THE FRONT LINE OF GAME INNOVflTION 



PLAN 




Fast, Cheap, and 
Out of Control 



This past July I was fortunate 
to fly out to M onte Carlo for 
Medpi, a gathering of game 
publishers and representa- 
tives from the largest French game dis- 
tributors. In a sense it's like E3, except 
that the entire Medpi exhibition area 
could have fit within Nintendo's E3 
booth. During my second day at the 
show, I met a developer on the show 
floor who works for a major game 
development/publishing company. As 
we toured his company's booth and he 
demonstrated their upcoming titles for 
me, we began discussing movies — The 
Phantom Menace, specifically. This guy 
told methat the official release date for 
TPM wasn't until October 13, but con- 
fessed he'd already seen the movie — 
he had downloaded it from the Inter- 
net. I was taken aback. 

Ethical issues aside, the thought of 
downloading a few hundred individual 
movie segments from alt.binaries.multi- 
media, piecing them together, and then 
watching the results on my 15-inch 
computer mon i tor j ust i sn 't appeal i ng 
to me. Sadly, I have to admit it's not the 
risk/reward ratio that deters me, it's the 
work/reward ratio. The consequences of 
downloading an illegal movie, game, or 
song from the Internet are virtually 
nonexistent. While I'm pretty sure that 
the effort required to do so forces many 
people simply to use the legal channels, 
it's still way too easy these days to 
download digital content illegally. The 
sheer volume of pirated media available 
I eaves I i tt I e d ou bt t h at en f o rci n g i n tel - 
lectual property laws is going to be one 
of the biggest law enforcement chal- 
lenges in the coming century. It will 
exert downward pressure on publisher 
revenues and developer royalties, and 
keep game (and probably movie and 
CD) prices higher than necessary. 

And then there's the flip side to the 
coin. What happens when other enter- 
tainment media embrace the Internet 
as a (or the) primary means of deliver- 
ing their content? Music, of course, is 
well down this path already, thanks to 
formats such as M P3 and RealAudio, 
and support hardware I ike the Dia- 
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mond Rio. If major motion picture stu- 
dios, television networks, radio sta- 
tions, and record labels decide that the 
time's right to push their content onto 
the Internet (I'm talking in a major 
way — not the half-hearted attempts 
we're seeing today), what will that do 
to game sales? Will the competition 
from other forms of digital entertain- 
ment mean opportunities for game 
developers, or will it threaten the pre- 
eminence of games as computer-based 
digital entertainment? 

Whilethe current retail model for 
games is far from dead and competition 
from other forms of digital entertain- 
ment is still nascent, we all need to be 
prepared for a completely wired, digital- 
ly integrated world. The Internet will 
have a major impact on game develop- 
ment and distribution next century, 
an d I ' m CO n vi n ced t h at as t h e I n tern et 
matures as a delivery mechanism, it will 
continue to benefit the game industry. 

To what extent we'll feel the pinch of 
piracy and competition from other 
forms of media as the Internet evolves 
is anyone's guess. Piracy enforcement 
itself may be too tough to overcome. It 
may require gigantic changes in the 
current business model of game pub- 
lishing, or an advanced licensing 
scheme based on advanced encryption 
technology not yet invented. Much of 
tomorrow's popular software (such as 
Linux) will be a free commodity which 
drives ancillary money-making busi- 
nesses, I ike training or consulting. In 
gaming, the model might be to distrib- 
ute free games and charge a fee to par- 
ticipatein professional leagues or 
against other players online. 

Like the title of Errol Morris's wacky 
1997 documentary, the Internet of the 
next century is going to be "fast, cheap, 
and out of control." In that climate, 
governments must be prepared to step 
up enforcement of intellectual property 
laws, and games companies must step 
up to compete against (or cooperate 
with) other forms of media. ■ 



DEVELOPER 

600 Harrison Street, San Francisco, CA 94107 

t: 415.905.2200 f: 415.905.2228 w: www.gdmag.com 

Publisher 

CyntliiaA. Blair cblair@mfi.com 

EDITORIAL 

Editorial Director 

Alex Dunne adunne@sirius.com 
Managing Editor 

Kimberley Van Hooser kvanhoos@sirius.com 
Departments Editor 

Jennifer Olsen jolsen@sirius.com 
Art Director 

Laura Pool lpool@mfi.com 
Editor-At-Large 

Chris Hecker checker@d6.com 
Contributing Editors 

Jeff Lander jeffl@darwin3d.com 

Mel Guymon mel@surreal.com 

Omid Rahmat omid@compuservecom 
Advisory Board 

Hal Barwood LucasArts 

Noah Falstein Thelnspiracy 

Brian Hook id Software 

Susan Lee-Merrow Lucas Learning 

Mark Miller Harmonix 

Paul steed id Software 

Dan Teven Teven Consulting 

Rob Wyatt DreamWorks I nteractive 

ADVERTISING SALES 

Western Regional Sales Manager 

Jennifer Orvik e: jorvik@mfi.com t: 415.905.2156 
Eastern Regional Sales Manager/Recruitment 

Ayrien Houchin e: ahouchin@mfi.com t: 415.905.2788 
International Sales Representative 

Breakout Marketing e: breakout_mktg@compuservecom 

t: +49 431 801703 f:+49 431 801797 
ADVERTISING PRODUCTION 

Senior Vice President/Production Andrew A. Mickus 

Advertising Production Coordinator Dave Perrotti 

Reprints Stella Valdez t: 916.983.6971 

MILLER FREEMAN GAM E GROUP MARKETING 
Group M arketing M anager Gabe Zichermann 
MarComm Manager Susan McDonald 
Marketing Coordinator Izora Garcia de Li I lard 

CIRCULATION 
Vice President/Circulation Jerry M . Okabe 
Assistant Circulation Director Sara DeCarlo 
Circulation Manager Stephanie Blake 
AssistantCirculation Manager Craig Diamantine 
Circulation Assistant Kausha Jackson -Grain 
Newsstand Analyst JoyceGorsuch 

INTERNATIONAL LICENSING INFORMATION 
RobertJ .Abramson and Associates Inc. 

t: 914.723.4700 f: 914.723.4722 
e: abramson@prodigy.com 

Miller Freeman 

A United News & Media publication 

CEO/M iller Freeman Global Tony Ti 1 1 i n 
Chairman/Miller Freeman Inc. Marshall W. Freeman 
President/CEO Donald A. Pazour 
CFO Ed Pinedo 

Executive Vice Presidents Darrell Denny, 

Galen A. Poss, Regina Starr Ridley 

Sr. Vice Presidents Annie Feldman, Howard I. Hauben, 

Wini D. Ragus, John Pearson, Andrew A. Mickus 

Sr. Vice President/Development Solutions Group KoAnn 
Vikoren 

Group President/Division SFl Regina Ridley 



www.gdmag.com 



Back 




New Products 



btf Jennifer Ol^en 



Whip 3D Models into Shape 

RAINDROP GEOMAGIC has introduced 
Shape, a new 3D modeling tool 
designed to relieve artists and designers 
of the ponderous methods associated 
with creating high-quality NURBS mod- 
els. Not all designers are great mathe- 
maticians, after all, and vice versa. 

With Shape, users can start with 
data from a physical object scanned 
and modeled in Geomagic Wrap, or 
import polygonal data from various 
3D file formats. Shape then generates 
NURBS patches based on an automati- 
cally computed patch layout, lays a 
grid structure on each patch, and fits a 
NURBS patch to each grid. Adjacent 
NURBS patches are guaranteed to be 
connected seamlessly, unless the user 
specifies otherwise. Shape's tolerance 
function can then evaluate the 
approximation of the NURBS surface 
by comparing it to the original polygo- 
nal data, and map a color-coded toler- 



ance computation directly onto the 
NURBS surface. 

Shape runs on Windows 95/98/NT 
and IRIX. It's aval I able as a stand-alone 
or as a component of the new Geo- 
magic Studio, which also includes the 
polygon-reduction tool Decimatorand a 
new version of Geomagic Wrap. 
■ Raindrop Geomagic Inc. 

Research Triangle Park, N.C. 

(800) 251-5551 or (919) 474-0122 

http://www.geomagic.com 



Party with Particles 




RotoDV's Media Stack features unlimited layers, enabling 
users to implement just about any wacl<y idea. 



DIGIMATION has released Particle Studio, 
its new particle generation plug-in for 
3D Studio Max and the successor to 
Sand Blaster. 

It's difficult to imagine a game today 
that wouldn't incorporate some kind 
of particle system in its architecture. 
Particle systems are useful for handling 
a variety of common effects such as 
smoke, fireworks, fountains, stars, and 
did I mention explosions? 

Particle Studio works with an event- 
driven paradigm, breaking the particle 
system up into time-based events. Most 
particle systems work under a set of 

^ parameters created at 

the beginning of the 
system. In order to 
control the system 
over time, the user 
must either alter the 
original parameters, 
or use other tools 
such as space warps. 
With Particle Studio, 
users can define a 
new event with its 
own set of parameters 
at any point along the 
life of the particle sys- 
tem. Users can acti- 
vate or deactivate 
space warps in a simi- 
lar fashion when each 
new event is created. 



New Products: Raindrop Geomagic 
simplifies NURBS, Digimation dishes 
out Particle Studio, and Digital Origin 
debuts RotoDV. p. 9 



Industry Watch: Nintendo's Dolphin 
strategy, Acti vision's big game hunt, 
and the latest from EA Sports, p. 10 



Product Review: Dan Teven takes 
Virtools' NeMo for a test drive in rapid 
game development, p. 12 



Particle Studio comes with three 
plug-ins: Particle Studio, Particle Studio 
helper, and the Particle Studio Snap- 
shot utility. It is priced at $595, with 
discounts available to current Sand 
Blaster users. 

■ Digimation Inc. 
St. Rose, La. 
(504) 468-7898 
http://www.digimation.com 

DV Effects in Real Time 

DIGITAL ORIGIN has begun shipping 
RotoDV, its new Macintosh -based digi- 
tal video manipulation tool for roto- 
scoping, special effects, animation, and 
touch-ups. RotoDV offers real-time 
playback at full resolution, depending 
on RAM availability, enabling users to 
view their work quickly as they go. 

With native QuickTime architecture, 
RotoDV promises to make fast friends 
with many other non-linear video edit- 
ing tools you and your team might be 
using, including Adobe Premiere and 
Digital Origin's EditDV, and it plays well 
with compositing applications such as 
Adobe After Effects. 

Users can customize RotoDV's 
brushes by setting and linking differ- 
ent parameters, enabling a wide vari- 
ety of effects. Replicator brushes can 
transfer certain images or entire frame 
sequences from frame to frame or 
layer to layer, even during playback. 
The Media Stack offers unlimited paint 
and video layers for endless combina- 
tions, and the layers are n on -destruc- 
tive — handy for anyone who has ever 
accidentally marred a treasured video 
clip in a fit of creativity. 

Available for Mac OS 8.5 or higher, 
RotoDV has a suggested retail price of 
$699, with special introductory pricing 
available on a limited basis. 

■ Digital Origin Inc. 
Mountain View, Calif. 
(650) 404-6000 
http://www.digitalorigin.com 
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Industry Watch 



btf Dan Hwebner 

CHANGES AT LUCASARTS. The summer 
of Star Wars may have tempted some 
Lucas employees to follow Anakin 
Sky walker's lead by leaving the nest. A 
series of recent departures from Lucas- 
Arts Entertainment, including Rogue 
Squadron project leader Mark Haigh- 
Hutchinson, Grim Fandango lead pro- 
grammer Brett Mogulefsky, along with 
several others in various departments, 
culminated in the resignation of eight- 
year Lucas veteran and director of pro- 
duction Steve Dauterman. Though 
Dauterman's parting was amicable and 
there doesn't seem to be a connection 
between the departures, rumors around 
the ranch suggest that other executive 
exit visas may be pending. 

CHEAP FISH. Nintendo seems to be 
planning to follow the example of its 
own Game Boy by bringing its next- 
generation console to market at the 
lowest price possible. Though competi- 
tors Sony and Sega are offering pricey 
thrills such as 56K modems and DVD 
movie playback, Nintendo plans on cre- 
ating a stripped-down version of its 
upcoming Dolphin that some analysts 
believe could be priced as low as $99. 
This low-cost Dolphin would not be 
able to play CDs or DVD movies, nor 
would it be likely to include a modem. 
Nintendo's partner, Matsushita, will 
produce a fully loaded model with DVD 
and CD functionality. Though $99 may 
be a bit unrealistic, anything approach- 




ing that would still put Dolphin well 
below the $340- $440 Playstation 2 price 
that was floating around the Tokyo 
Game Show. 

ULTIMA ASCENDANT. Origin Systems is 
consolidating its efforts into massive 
multiplayer online worlds. Following on 
the success of Ultima Online, Origin is 
canceling production of Jane's AlO 
Warthog at its Austin, Tex. studio. 
Those working on thefighter jet title 
are to be relocated to other projects 
within the company. Warbird flight fans 
need not worry. Origin parent 
Electronic Arts plans to continue Jane's 
Simulations series at another studio. 

ACTIVISION BAGS BIG GAME HUNTER. 

Demand for hunting games has 
remained strong, and Acti vision has 
renewed its commitment to this unex- 
plainable market segment by acquiring 
Florida-based Elsinore Multimedia. 
Despite a name that conjures up images 
of a brooding Hamlet, Elsinore is the 
creator of Wal-M art favorites Cabela's 
Big Game Hunter I and II. Elsinore had 
previously been published by Activision 
label Head Games, and now joins as a 
wholly owned subsidiary. 

EA GOES HANDHELD. Slackers who 
spend weeks at a time tied to EA 
Sports' football and hockey offerings 
may finally have a reason to get off the 
couch. Electronic Arts has entered into 
a deal with Radica Games, best known 
for developing shaking electronic bass 
fishing games, to take EA's sporting 
line mobile. Radica will bring these 
franchises to market as EA Sports brand 
handheld electronic games, which will 
more than likely beep and vibrate their 



Radicals handheld line will soon fea- 
ture EA Sports titles. 



way into the hearts of Madden fans 
everywhere. Radica will also hold the 
right of first refusal over any game in 
the EA line. 

FURNITURE-FRIENDLY DEATHMATCH. 

Deathmatches are about to become a 
whole lot safer when Hasbro and 
Visionary Media bring us Nerf Arena 
Blast. Though it may seem a bit incon- 
gruous at first glance, Nerf and 3D first- 
person shooters are actually very simi- 
lar: both allow players to kill each other 
violently with exotic looking weaponry 
without scuffing the furniture. Put the 
two together and you have mayhem the 
whole family can enjoy. The game was 
developed using the Unreal engine. ■ 



UPCOMING EVENTS 

CALENDAR 



ECTS '99 

OLYMPIA CONVENTION CENTRE 
London, England 
September 5-7, 1999 
Cost: variable 
http://www.ects.com 

Game Developers Conference 
1999 Rood Trips 

BATTERYMARCH CONFERENCE 
CENTER 

Boston, Mass. 
September 8, 1999 

NAVY PIER CONFERENCE CENTER 
Chicago, III. 
September 10, 1999 

RALEIGH CONVENTION AND 
CONFERENCE CENTER 

Raleigh, N.C. 

September 13, 1999 

SEQUOIA CONFERENCE CENTER 
Buena Park, Calif. 
September 27, 1999 

Cost: $120 ea. (discounts available) 
http://roadtrips.gdconf.com 
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Virtools' 
NeMo 



btf DaM Teveit 



Virtools wisely avoids the 
phrase "Rapid Application 
Development" when it 
describes NeMo. So-called RAD tools 
make me think of the control I'm giv- 
ing up, not the speed I'm gaining. So I 
was pretty amazed when I realized that 
NeMo is a Rapid Game Development 
tool — and Mike it. 

NeMo comes in two flavors, NeMo 
Creation and NeMo Dev. Both let you 
create a 3D world populated with 
dynamic objects and assign behaviors 
to those objects. Using Creation, you 
can develop simple games that run in a 
special player or "gamelets" that run in 
a browser. With Dev, which adds an 
SDK for C-H-, you can integrate NeMo 
into your own application. 

To its credit, Virtools doesn't push 
you to buy Dev right off the bat. They 
believe most people need to create 3D 
prototypes, demos, or multimedia pre- 
sentations. If you need the extra flexi- 
bility of Dev, you can upgrade easily. 
CONCEPTS. At its heart, NeMo is a 
library that implements the concept of 
a behavior, coupled with a scene man- 
agement database, a simulation 
engine, and a library of more than 200 
stock behaviors. It's not a rendering 
engine, but it can use Direct3D or 
OpenGL. You use the NeMo environ- 
ment built on top of these compo- 



nents to engineer your content; you're 
only exposed to the low-level inter- 
faces through the SDK. 

NeMo organizes data into levels, 
scenes, places, and groups. These con- 
tain 2D and 3D entities: 3D objects 
(made of meshes, materials, textures, 
and sounds) plus sprites, curves, cam- 
eras, and lights. Characters are just col- 
lections of 3D entities. Although some 
behaviors are character-specific, most 
are generalized, so you can build a 2D 
sprite game if that's your goal . 

You'll need to create most of your 
data with third-party tools. Although 
NeMo can handle the .X file format, it 
seems better suited to .3DS — many of 
the standard behaviors seem to map 
directly to 3D Studio Max modifiers. 
You can import the usual 2D and audio 
formats. Afterwards, you can do all the 
integration, behavioral scripting, 
debugging, and tuning work in the 
NeMo environment. 

A behavior is a program associated 
with an object, allowing the object to 
change during the simulation. In NeMo, 
anything can have a behavior. An obvi- 
ous character behavior is "wait for a 
mouse click, then walk to theclicked-on 
object." But behaviors can also be used 
to make tracking cameras, procedural 
textures, levels that keep score, and just 
about anything else. 
THE ENVIRONMENT. NeMo's user inter- 
face is a mixed bag. Virtools deliber- 
ately strove for a tool that looks differ- 
ent from other Windows applications, 
and the result has loads of style. I love 
the overall look, the way you can 
accomplish almost anything with drag 
and drop, and the way you can play 
your content without having to wait 
for compilation. 

I really love the filter graph (flow- 
chart) metaphor for creating behaviors. 
You don't need to write a line of code 
— just drag behaviors from the Build- 
ing Blocks pane into the Schematic, 
click to connect the appropriate pins, 
set parameters through a dialog box, 
and you're ready to roll. 

You can really get work done in this 
environment. TheTrace mode (show- 
ing the active behaviors in real time by 
highlighting them in red) is cool, and 



Dan Teven specializes in systems architecture for game development. He's always 
wondered why a solitaire game comes with Windows. Sue him for pointing this out 
at dteven@ici.net. 



there's breakpoint and single-step sup- 
port. There's also an integrated profiler. 

Although it's attractive, the U I is 
maddeningly inconsistent. Only a few 
of the commands are available from the 
menu bar, so you have to learn a lot of 
special-case controls. Sometimes right- 
clicking works, sometimes it doesn't. 
M any controls are close at hand on the 
window borders, but few are associated 
with tool tips. The help is not context- 
sensitive. And it's risky to click blindly, 
because there's no undo. 

I'm not crazy about the windowing. 
On-screen, there are three tiled, non- 
resizable window frames, and each can 
hold multiple tabbed panes. You zoom 
windows to full screen by double-click- 
ing on the tab, not the top border. You 
can drag panes from one frame to 
another to make the best use of space, 
but it's too easy to inadvertently open a 
new pane, which causes the one you 
were working with to vanish (actually, 
the tab scrolls out of view). And, there's 
no consistent way to close windows. 

Tree controls let you explore the data 
and behavior hierarchies. These are ade- 
quate, but limiting. It would be nice if 
certain behaviors appeared more than 
once under Building Blocks. For exam- 
ple. Character Prevent from Collision 
should be listed under both Collision 
and Character. 

I found NeMo to be very keyboard- 
unfriendly. For some reason, Alt-F 
doesn't bring down the File menu, 
even though the F is underlined. The 
behavior that steers a character around 
in the tutorial works with the keypad 
arrows, but not the special -purpose 
arrow keys. And, if you play your scene 
in full screen mode, theonly way to 
get back is by Alt-Enter. (I tried mouse 
clicks. Esc, Enter, spacebar, all the func- 
tion keys, Alt-Tab, and Ctrl-Alt-Del 
before I figured this out.) 

Even the color scheme — blacks and 
grays— is problematic. By shunning 
color in the interface, Virtools makes 
the content look better. But this makes 
it harder to tell when a control con- 
tains editable text, or even which win- 
dow has the focus. 

BEHAVIORS. Creating reusable behaviors 
with NeMo couldn't be easier. You can 
collapse a filter graph into a black box 
that behaves just I ike an atomic behav- 
ior. You can name your compound 
behavior and annotate it with com- 
ments and screen snapshots. When 
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you use it, NeMo will create the "Edit 
Parameters" dialog box on the fly. 

With Dev, you can create new 
behaviors in Visual C-H-. These will 
show up in Building Blocks and the 
help system, and they'll work normally 
in the schematic, except you won't be 
able to expand the black box. All the 
stock behaviors were built with the 
SDK, and their source is included. 

Some of the stock behaviors go far 
beyond what I expected. There are lots 
of mesh modifiers, including a mor- 
pher and a skin-join, and there are 
eight kinds of particle systems. There 
are some interesting camera effects, 
such as vertigo. There's an interpolator 
that works in HSV color space and one 
that works along a 2D Bezier curve. 
Many rendering effects, such as 
motion blur, are also available. The 
leverage you get with NeMo, right out 
of the box, is really impressive. 
DOCUMENTATION. Except for the lack of 
an undo function, the Ul problems 
are superficial. If you're looking for an 
Achilles heel in NeMo, look to the 
documentation. 

Creation has a paper manual that will 
get you up and running, but it runs out 
of steam soon after that. Parts of the 
Advanced Topics section read like a pro- 
grammer's notes on a napkin. There's 
also an online reference; the two 



together are barely adequate. Dev has 
plenty of sample code and another 
online reference, labeled "under con- 
struction," and it assuredly is. 

What's missing? High-level informa- 
tion about the architecture, so you can 
understand how NeMo is put together, 
and how you can extend it through the 
SDK; more step-by-step, task-oriented 
tutorials; the technical details of behav- 
iors and parameter operations; docu- 
mentation of the debugging tools; doc- 
umentation of preferences; a full index; 
and search ability. Dev would benefit 
from templates for behaviors, or even a 
wizard that generates them for you. 



SinceVirtoolsisa French 
company, there are occa- 
sional bad translations. The 
meaning is usually obvious 
— as in "2eme param" — 
but in a few places the awk- 
ward translations affect "lisi- 
bility." The terminology can 
be strange: I might have 
chosen the terms "local" 
and "global" instead of 
"place" and "trans-place." 

At least there's an active 
user group. On Virtools' 
web site, you can ask ques- 
tions, share techniques, and 
show off your work. Since 
NeMo will introduce a lot 
of newcomers to real-time 
3D, Virtools hopes the user 
group can provide the back- 
ground culture required to 
master concepts, such as 
efficient collision detection 
and optimized rendering. 
PROTOTYPE OR PRODUCTION? 
Currently, Dev lets you create 
behaviors, integrate the engine into 
your application, plug in your own ren- 
derer, and create import plug-ins. The 
architecture looks modular, and in the- 
ory you can interface NeMo to just 
about any external engine. Discreet is 
currently using NeMo as a test bed for 
releasing core 3D Studio Max R3 char- 
acter animation algorithms as game 
engine components. 

NeMo Dev has tremendous poten- 
tial, but until the documentation's fin- 
ished I can't recommend it for produc- 
tion. NeMo Creation has some 1.0 
flaws, but it's Rapid Game Develop- 
ment at its best. ■ 



NeMo Creation: NeMoDev: 



Virtools S.A. 

Paris, France 

+33 (i) 42-71-46-86 

http://www.nemo.com 

Price: Creation is $990 per 
seat. Dev is $3,490 plus 
a negotiable license fee. 

System Requirements: 

Pentium 200, 48IVIB 
RAIVl,Direct3D or OpenGL 
accelerator, 60IVIB disk 
space, Windows 
95/98/NT4.0, DirectX, 
Internet Explorer 4. 
X 



Pros: 

1. Flowchart metaphor lets 
you create behaviors 
rapidly without coding. 

2. Behaviors can be 
smoothly reused, com- 
bined, and extended. 

3. The impressive selection 
of canned behaviors 
makes it a great proto- 
typing tool. 



Cons: 

1. The documentation 
ranges from spartan 
(Creation) to woeful 
(Dev). 

2. Inconsistent user inter- 
face. 

3. Dev isn't mature enough 
to rely on for production 
— yet. 
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GRAPHIC CONTENT 



Physics on the Back 
of a Cocktail Napldn 



am generally pretty disciplined about working normal hours during the week. 
However, on Fridays I I ike to shoot pool and eat pizza at the local sports bar. 
Since happy hour starts at three, I sometimes need to move work down the 
street. I was working out how to win a serious game of nine ball when oneof 



those geeky discussions broke out 
about pool table physics. Pool, like 
many sports, is dominated by the laws 
of physics. Good players have an excel- 
lent senseof theapplication of force, 
thephysics of collisions, and theinflu- 
ence of friction on objects in motion. 

Last month I described how friction 
could be used to increase the realism of 
the physics model in real-time games. 
The demo program made it possible to 
see how various coefficients affected a 
mass-and-spring model. However, it 
wasn't very much fun. In order to 
demonstrate how a solid physical foun- 
dation can actually create interesting 



game play, I need to pull some of these 
concepts together into a real applica- 
tion. A pool table simulation is a natur- 
al choice. It will allow me to apply 
many of the techniques I have covered 
as well as provide some ideas that can 
be converted easily to other sports such 
as golf or tennis. 

Two Ball, Corner Pocket 

In order to understand pool, I need to 
understand collisions between bil- 
liard balls. Fortunately, billiard balls are 
all spheres of equal size and weight. 




Like most things in life, pool provides an excellent venue for a physics lesson. 



That makes the collision calculationsa 
bit easier. Let me begin by looking at 
the friction I ess case. I suspect that if I 
ignorethe ball's rotation and do not 
consider friction, the ball collision will 
behave exactly I ike a parti cleat the 
ball's center of mass. That would be 
great, as I could use the code from a pre- 
vious column. However, I want to make 
sure. Figure 1 shows a typical collision. 

Ball A is moving at a speed of 20 
feet per second and collides with ball 
Bat a 40 degree angle. In order to 
determine the velocity of each ball 
after the collision, I need to apply 
dynamics. A collision between two 



V 


Velocity of body (vector) \ 


m 


Mass of a body 


£ 


Coefficient of restitution 


n 


Line of collision or collision normal 


t 


Line tangent to collision 


i 


Impulse force 


N 


Force normal to surface 


9 


Gravitational force 


^5 


Coefficient of sliding friction 




Coefficient of rolling friction 


R 


Radius of the ball 


1 


Inertia tensor 


0) 


Angular velocity 


a 


Angular acceleration 


r 


Vector from center of mass to 
point of contact 


TABLE 1. A summary of the notation 
used in this article. 



W hen not wasting time at the pub eating hot wings and shooting pool, Jeff can be found at Darwin 3D. There he creates real-time 
3D graphics for a variety of applications. Drop him a Iineatjeffl@darwin3d.com. 
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rigid bodies, which occurs in a very short time and during 
which the two bodies exert relatively large forces on each 
other, is called an impact. The force between these two 
bodies during the collision iscalledan impulsive force, 
which is symbolized by j. The common normal to the sur- 
faces of the bodies in contact is called the line of collision, 
represented as n in Figure 1. 

Thefirst step is to break the initial velocity of ball A into 
its components along the lineof collision, n, and thetan- 
gent to the collision, t. 

= 20 ft / sec 
{y^.n) = y, cos(40) = 15.32 ft / sec 
(V, • t ) = V, sin(40) = -12.86 ft / sec 

The impulsive force acting during thecollision isdirected 
along the lineof collision. Therefore, thet component of the 
velocity of each ball is not changed. 

(v; tj^ -12.86 ft /sec 

(v^ tl^ Oft/sec 

In order to determine the new velocity along the lineof 
collision, I need to look at the impulsive force between the 
bodies. The impulse acts on both bodies at the same time. 
You may remember Newton'sthird law of motion, theforces 
exerted by two particles on each other are equal in magni- 
tude and opposite in direction. 

Since the impulse forces are equal and opposite, momen- 
tum is therefore conserved before and after thecollision. 
Remember that the momentum of a rigid body is mass times 
velocity (mv). 

mjv; ■n)+n)^{y;-n)= mjv; -nj + mJvB -n) 

m(15.32)+ m(0) = m^Cv; • n)+ ro^iy'^ ■ n) 

(v; nl + Cv^ n) = 15.32 

This equation can't be solved without some more infor- 
mation. In my column "Collision Response: Bouncy, 
Trouncy, Fun"(Graphic Content, March 1999), I discussed 
the coefficient of restitution. This is the scalar value 
between Oand 1 relating the velocities of bodies before and 



after a collision via theformula: 

K ri)-{y; n) = 8[{y, n)-{y, n)] 2) 

For this example, I'm using a coefficient of restitution e 
of 0.8. I can use this formula to create a second equation. 

(v^n)-(v;n)=0.8[(15.32)-(0)] 
K n)-(v;.n) = 12.26 

Solving Equations 1 and 3, 1 get the velocities of the two 
billiard balls after thecollision. 

v; =(1.53,-12.86) ft /sec 

=(13.79, 0.0) ft /sec 

In order to solve this problem in the simulation, I need to 
derive the impulse force directly. The impulse force creates a 
change in momentum of the two bodies with the following 
relationship. 

m,v, +jn = m,v; 
m,v, - jn = 



Vg = Vg — — n 

(Eq. 4) 

These formulas can be combined with Equation 2 to deter- 
mine th e i m pu I se force gi ven th e rel at i ve vel oci ty an d th e 
coefficient of restitution. 

-(l + £)v,g-n 



n • n 



1 




(Eq. 5) 

You can plug Equation 5 back into the example problem 
and make sure it works. Remember that because of Newton's 
third law, the impulse is equal and opposite for the two col- 
liding bodies. When you apply Equation 5 to the B ball, 
remember to negate it. 
Those of you who read Chris Hecker's column on colli- 
sion response ("Physics, Part 3: Collision 
Response," Behind the Screen, February/ March 
1997) will recognize Equation 4 as the impulse 
equation for a general body that does not 
rotate. When we do not consider the rotation 
of the billiard balls, they behave exactly like 
the particles used in my March 1999 mass-and- 
springdemo. My suspicion was correct, and I 
can use the particle dynamics system as a base 
for the demo. 

I For many applications, this would probably 

be more than enough to get a decent physical 
simulation. In fact, I imagine many pool simu- 
lations end right there. This level of simulation 
is probably sufficient for other games, such as 
pin ball. However, anyone who has played 
much pool knows that this is not the end of 
the story. The rotation of the ball caused by the 
reaction with the table makes a tremendous 
difference in the realism of the simulation. 




FIGURE 1. A simple collision between two billiard balls. 
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FIGURE 2 . A billiard ball sliding across the table. 



Slip Sliding Away 



(Eq. 6) 



When a billiard ball is hit with thecue 
sti ck, th e bal I starts movi n g across th e 
table. If the bal I isstruck along itscenter of mass, 
the ball is not initially rotating. 

However, soon the bal I starts rolling along. 
Friction between the ball and the table causes 
this roll to occur. You can see this situation in 
Figure 2. 

The ball is traveling with the forward veloci- 
ty, V. In last month's column ("TheTrials and 
Tribulations of Tribology," Graphic Content, 
August 1999), I discussed the use of kinetic 
friction via the Coulomb dry friction model. 
For our purposes, I'm going to call thisforce 
"si i d i n g f ri cti on . " Th e force of f ri cti on appi i ed 
to a body sliding over a surface is given by the 
following formula: 

f = = jiis^Q 

Thefriction force is applied in the direction opposite the 
velocity. Si nee this force is applied to the surface of the bal I 
and not itscenter of mass, thefrictional force causes angular 
acceleration in the ball. As the ball rolls across the table, the 
angular velocity increases because of this sliding friction 
force. This continues until a time of equilibrium is reached, 
where the velocity of the point contacting the table equals 
the velocity of the center of mass. At this time, the ball is no 
longer sliding and is now rolling on thetable. Thissituation 
iscalled a natural roll or rolling without sliding. In mathe- 
matical terms, thissituation happens when 

(Eq.7) 

wherev isthevelocity of theball, w istheangular velocity of 
the ball, and R is the ball's radius. 

Now I need to show how the angular acceleration actually 
changes. This is going to mean bringing up another term, 
the inertia tensor, or I. You may remember from Chris 
Hecker's column on 3D physics ("Physics, Part 4: The Third 
Dimension," Behind the Screen, June 1997) that the inertia 
tensor relates the angular velocity of a body to the angular 
momentum of that body. For arbitrarily complex objects, 
creating the inertia tensor can be quite difficult. However, 
for a uniform sphere where the density is uniform across the 
sphere, it's quite easy. The inertia tensor for a sphere is 



I = 



2mR' 



(Eq. 8) 

Therefore, the product of this matrix with any vector is a 
simple scaling of that vector. The relationship between the 
angular acceleration and thefriction force then becomes 



a = 



a = 



rxf 



I 

rxf 



5(rxf ) 
2mR' 



^ (Eq. 9) 

If I now take a look at the problem in Figure 2, 1 can calcu- 
late how long it will take for the bal I to achieve natural roll 



given an initial velocity v. From the principle of impulse and 
momentum, I know some information about the linear 
momentum and angular velocity of theball at a later time. 

mv' = mv-f (At) 



0) 



f(At)r 5f(At) 



I 2mr 

In other words, the momentum at some later time is the 
initial momentum minus the impulse created by thefriction 
force, f. I know thefriction force from Equation 6. 

mv' = mv- ;Usmg(At) 

2r 

At the point of natural roll, I know the state of equilibri- 
um between angular and linear velocity from Equation 7. 



5/isg(At) 



2r 



v-;asg(At) 



(^ + /isg)(At)^ 



At = 



2v 



So you can see that as a result of thefriction force of the 
table, a sliding billiard ball will always reach a point where it 
is rolling without sliding on thetable. This isthetypeof 
realism I want to have in thesimulation. A ball when struck 
should slide across the table, slowly settling to a state where 
it is rolling without slipping. 



How Do I Stop This Crazy Thing? 

One glaring problem remains. I can run thesimulation 
with all of the physics discussed so far. When struck 
hard, a billiard ball will slide and then roll. Once the ball has 
reached this natural roll, there is nothing in my simulation 
that will keep it from continuing to roll forever. Thefriction 
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force is gone si nee the point of contact is not moving rela- 
tive to the table. I need to add another force that will slow 
down a rolling ball. I can add another friction al force, called 
rolling friction, which isapplied when theball is in natural 
roll. Theform of rolling friction is 

It is applied exactly like the sliding friction whenever the 
natural roll conditions apply. It is important to note that 
the coefficients of rolling and sliding friction are not neces- 
sarily thesame. Think of a ball moving on a rubber surface. 
The coefficient of sliding friction would be very high. How- 
ever, the rolling friction would be comparatively low, allow- 
ing the ball to roll across the surface easily. 



Bumpin the Cush 

Collision with the table's side cush ion scan behandled in 
a couple of ways. If I consider the table to be completely 
3D, I will need to handle 3D collision between theball and 
thecushion. That would be the most realistic. It would allow 
theballsto move up and down as well as side to side. This 
might be interesting if I wanted to beableto perform a jump 
shot (when the cue ball jumps up and over other balls on the 
table). However, I'm not really ready to tackle the physical 
and interface issues involved in making this happen. 

If I'm willing to give up the flexibility of allowing the balls 
to move in 3D, things become a bit easier. Foronething, I 
can eliminate the gravitational force acting on theball. A 
ball sitting on a table is in a constant collision battle with 
the table top. By getting rid of the gravitational force, I save 
having to deal with theball constantly interpenetrating the 
table. I still need to keep track of the gravitational force as it 
is used in calculating the friction force applied by the table. 
However, I just assume the balls are in constant sliding or 
rolling contact with thetable. 

Also, if I ignore vertical motion of the balls, I can turn the 
collision with the side cushions into a 2D computational 
geometry problem. The boundaries of the table are now line 
segments and I can usethe2D collision detection routines 
developed in my column "Crashing into the New Year" 
(Graphic Content, January 1999). 

Later, I may wish to allow the balls to jump. It would then 
be easy enough to convert the collision back to 3D. These 
kinds of decisions are made all thetime during the game 
production process. Since game simulation is all about speed 
versus realism, simplifying the problem if it works for your 
particular application makes sense. 



Rack Up 

Using these techniques, I have created a demonstration 
of a simple pool table. The simulation uses rolling and 
sliding friction to simulate the way a real billiard ball 
movesacrossa table. Collision between balls is handled 
through conservation of momentum and the elastic colli- 
sion model. There are several areas that still need work. Of 
course, I didn't talk about applying "English" to the shot 
by striking the ball off the center of mass. This technique is 
what makes shots such as a Masse, draw, ortopspin possi- 
ble. This is largely just a matter of where the impulse from 
the cue stick isapplied. Also, the lack of friction between 
colliding balls does not allow effects such as collision- 
induced spin. 

Another problem arises when we consider simultaneous 
collision between several billiard balls. When calculating 
the resulting force when two balls collide, it was fairly easy 
to determinethe resulting force. However, when several 
balls collide simultaneously, the law of conservation of 
momentum becomes much harder to enforce. In order to 
calculate the resultant forces correctly, I need to solve sev- 
eral simultaneous equations. Obviously, this tends to com- 
plicate things quite a bit. 

Alas, that will have to wait for another time. Until then, 
see if you can modify the source code to handle these 
effects. You can download the source code and the exe- 
cutable application off the Game Developer web site at 
http://www.gdmag.com. ■ 
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Raising the Bar: Content Creation 
for Next-Generation Hardware 



ecent years have seen the emergence of real-time 3D (RT3D) as the 
dominant venue for computer gaming. With the arrival of the Sega 
Saturn, Sony Playstation, and Nintendo 64, RT3D became an integral 
part of mass-market gaming. The "hardware-accelerated PC" followed 




shortly thereafter, and now many devel- 
opers consider it the standard target 
platform, a view that might have 
seemed n aive j ust a few years ago .While 
the advent of these revolutionary plat- 
forms set the stage for RT3D to become 
a standard, the next generation of con- 
soles (Sega's Dreamcast, Sony's Play- 
station 2 and Nintendo's much rumored 
Dolphin) and hardware accelerator 
cards promise to expand thetechnologi- 
cal boundariesof game development by 



a quantum leap, exponentially increas- 
ing the amount of digital canvas we 
developers have to work with. 

With this increase in capability 
comes a correspondingly higher level of 
expectation on the part of the con- 
sumer, and an increased burden on us 
as developers to evolve with and take 
full advantage of the new hardware. 
This month we'll scratch thesurface 
and attempt to predict some of the 
ways i n wh i ch th e arti sti c aspects of th e 



development process will be affected by 
the latest and greatest technology. 



More and Faster 

At the most basic level, the tech- 
nology advances can be distilled 
down to the following statement: You 
can display and manipulate much 
more content then ever before, and 
you can do this faster than ever before. 



Sony Playstation 2 Specifications 

CPU: 128-BIT "Emotion Engine" 

• 300MHz system clock frequency 

• Cache memory instruction: 16KB, Data: 8KB + 16KB (ScrP) 

• Main memory: Direct Rambus (Direct RDRAM) 

• 32MB memory size 

• 3.2GB per second memory bus bandwidth 

• Co-processor FPU (Floating Point Unit) 

Floating Point Multiply 
Accumulator x 1, Floating Point Divider x 1 
•Vector Units VUoandVUi 

Floating Point Multiply 

Accumulator x 9, Floating Point Divider x 3 

• 6.2 GFLOPS Floating Point Performance 

• 66 million polygons/sec 3D CG geometric transformation 

Graphics: "Graphics Synthesizer " 

• MPEG2 compressed image decoder 

• 150MHz clock frequency 

• 48GB per second DRAM bus bandwidth 

• 256-bit DRAM bus width 

• RGB: Alpha: Z-Buffer (24:8:32) pixel configuration 

• 75 million polygons/sec maximum polygon rate 

Sound: "SPU2+CPU" 

• Number of voices ADPCM: 48ch on SPU2 plus 
definable, software-programmable voices 

• 44.1KHZ or 48KHZ selectable sampling frequency 

CPU Core 

• Playstation (current) CPU 

• 33.8MHz or 37.5MHz selectable clock frequency 

• 32-bit sub bus 

• Interface types: IEEE1394, Universal Serial Bus (USB) 

• Communication via PC-Card (PCMCIA) 

Disc Device 

• CD-ROM and DVD-ROM 



Sega Dreamcast Specifications 

CPU: Hitachi SH-A 

• 20oMHz clock rate 

• 360MIPS (millions of instructions per second) 

• 1400MFI0PS (900MFI0PS with external memory) 

• 64-bit data bus 

• looMHz bus frequency 

• Capable of 5 million polygons/sec 

• 8ooMB/sec bus bandwidth 

• 32-bit integer unit 

• 128-bit floating point bus 

GPU: NEC PowerVRSG 

• looMHz clock rate 

• 32-bit bus 

• 9 billion operations/sec 

• 3.5 million polygons/sec 

• 120 million pixels/sec fill rate 

• Perspective-correct texture mapping 

• Bilinear and trilinear filtering 

• Anisotropic filtering 

• Gouraud shading 

• 32-bit Z-buffer 

• Colored light sourcing 

• 16 levels of transparency 

• Full-scene edge anti-aliasing 

• Fog vertex 

• Per-pixel fogging 

• Bump mapping 

• 24-bit color 

Sound: Yamaha ARM7 ASIC 

• 45MHz clock rate 
•40MIPS 

• 64 sound channels 

• Full 3D sound support 

(continued next column) 



(Dreamcast, continued) 
Modem 

• Upgradable 33.6KB per second transfer rate 

CD-ROM 

• Designed by Yamaha 

• iGB data storage 

• 12 speed 

• 1800KB data transfer rate 

Memory 

• 16MB main RAM 

• 8MB video RAM 

• 2MB sound RAM 

3dfx Voodoos 3500 Specifications 

AGP Texturing 
16MB SGRAM 

Internal clock and memory speed of 183MHz 
366 Megatexels/sec peak fill rate 

8 million polygons/sec 
Single-pass multi-texturing 
128-bit 2D/3D processor 
350MHz RAMDAC 

D3D, Glide, OpenGL support 

Video acceleration for DirectShow and MPEG 1&2 

Nvidia Riva TNT2 Specifications 

AGP Texturing 

32MB SDRAM/SGRAM 

9 million triangles/sec, 300 million pixels/sec 
2.9GB/sec bandwidth 

300MHz RAMDAC 
128-bit TwiN-Texel architecture 
Optimized Direct 3D and OpenGL acceleration 
Video accelerated for DirectShow, MPEGi and 2, 
and Indeo 



FIGURE 1 . A sampling of the next-generation hardware specifications that developers must contend with in the near future. 
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FIGURE 2 . Know when to splurge on polygons. At left, the polygon budget has 
been spent in facial details; at right, a more uniform polygon distribution. 



How much and how fast? See Figure 1 
for some of the nitty-gritty details. 
Depending on the game premise, it's 
not unfeasibleto be looking at on- 
screen polygon counts in the tens of 
thousands, and characters animating 
upwards of 60 frames per second. Our 
challenge as developers is to create 
enough content to showcase the tech- 
nology wh i I e at th e same ti me mai n- 
taining the high level of quality and 
polish which players have come to 
expect in today's RT3D games. 

Managing Polygon Counts 

Oneof thetoughest restrictions to 
meet in RT3D development is the 
target on-screen polygon count. Since 
almost every object displayed on-screen 
is made up of polygons, each object 
contributes to thetotal on-screen count. 
In order to keep the game running at an 
acceptabi e frame rate, arti sts are forced 
into a balancing act that pits quality 
against quantity; trying to keep the 
polygon count of each individual object 
high enough to maintain a certain 
graphical feel, yet low enough so that 
you can put enough interesting things 
on-screen to keep the player continu- 
ously occupied. With the latest hard- 
ware advances, on-screen polygon 
counts of 20-30,000 polygons per frame 
are now feasi ble. As artists, we can take 
advantage of th is by creati ng hyper- real- 
istic characters, or by populating our 
worlds with vast numbers of objects. 

Consider the images in Figure 2; the 
faceon theleft isthenow familiar 



image from the early PSX2 demos, while 
the character on the right is our much 
beloved Rynn, from Drakan. In the case 
of thefacial close-up, it's obvious that 
much of the detail has been spent on 
the character's head and face. In Rynn's 
case, a more uniform polygon distribu- 
tion results in a more curvaceous body. 
The extra polygons in thefacearenot 
needed for Rynn because her character 
i s u su al I y a set d i stan ce f ro m t h e cam- 
era. Figure 3 shows a landscape scene 
from Drakan with its current polygon 
count on the left (around 5,000 on- 
screen polygons) and a higher-resolu- 
tion scene, where all of the trees have 
been pumped up to around 1,000 poly- 
gons each (this yields an on-screen poly- 
gon count of around 50,000 polygons). 

So now we're back to the balancing 
act again, trying to decide where best 
to spend the extra polygon budget. 
This decision largely depends on the 
focus of the game play. For example, in 
a ground-based adventure game, where 
having an immersive environment is 



critical, it's easy to imagine spending 
10,000 polygons per frame on trees, 
rocks, and undergrowth. In a character- 
based fighting game, most of your 
detail can go directly into the charac- 
ters, model ingfin gers an d faces as wel I 
as weapons and special effects. 

In either case, the increased detail and 
definition comesatahigh development 
cost i n th at th e arti sts' ti me i n creases 
disproportionately with thedetail in the 
models. Consider how long it would 
take on e of you r arti sts to gen erate a 
model with only half as many polygons 
as the girl in Figure 2. What method 
would the artist use? Traditional poly- 
gon modeling methods would be 
tediousand time-consuming. Morelike- 
ly, the model would be built first with 
N U RBS, patches, or some other surface 
tool, and subsequently converted to 
polygons. The task, which might previ- 
ously have taken two to three days, may 
end up taking a week or two. And that's 
assu m i n g yo u r art i sts are al ready f am i I - 
iar with the techniques necessary to cre- 
ate the higher-resolution geometry. 

Don't fall into the technology trap. 
Add i n g po I ygon s to obj ects j ust f o r 
detail's sake can waste valuable time 
that should be spent on other areas. 
Take the time to plan out each scene 
efficiently, and prioritize the objects in 
the scene as they relate to game play 
and art direction. 



Texture Generation 

Even more important than polygon 
construction, textures on a RT3D 
object serve to flesh out the wireframe 
foundation and give the illusion of 
depth and detail. Oneof the main rea- 
sons you don't want to go overboard 
on the modeling isthat you need to 




FIGURE 3 . The landscape at left is comprised of 5,000 on-screen polygons. At 
right, each tree is around 1,000 polygons, causing the on-screen total to sl<yrocl<et. 
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FIGURE 4 . Gone are the days of single textures with alpha 
components. Today's textures have large extended families 
of modifier maps, compounding the artist's worl<load. 



save enough time to add asmuch detail as possibleto the 
textures in your game. And with texture memory footprints 
of 10MB or more, and data transfer rates clocking in giga- 
bytes per second, it seems odd to speak in terms of "limits." 

Thankfully, the days are behind us when our textures had 
to be 16 colors and 64 pixels square. With texture resolutions 
of 256 pixels square and higher, alongwith true-color bit 
depths, there's no limit to the level of realism we can achieve. 
And whereas we are usually forced to generate high -detail tex- 
tures fo r ch aracters an d I i m i 1 1 h e text u re si ze f o r en v i ro n - 
ments, with the increased texture memory (upwards of 16MB 
or more on some cards and platforms), it's now possibleto 
achieve photo-realism and a uniform pixel density in both 
the characters and environments concurrently. Additionally, 
we can now use streaming M PEG video as textures mapped 
onto 3D surfaces (an excellent tool for creating believable 
water, smoke, and pyrotechnics). 

Here again, the hardware's increased capabilities prove to 
be a double-edged sword. The larger and more detailed the 
texture, the longer an artist has to spend generating it — and 
consequently, fewer textures can be created in any given time 
period. Where once we only had to worry about a single tex- 
ture with its alpha component, now each texture has a multi- 
tude of options and fancy gimmicks from which to choose. 
Figure 4 shows an exam pie of how a single texture map can be 
modified with the addition of several modifier maps. In addi- 
tion to the main texture map, we also have the following: 
luminescence, for self-illuminating maps (objects that have a 
glow about them); environmental maps for reflective surfaces 
(water, metals, glass, and so on); "detail" textures to add ran- 
dom diversity to surfaces (fractal- or noise-based, these can act 
independently of existing mapping coordinates so that as you 
get closer to the object, the perceived detail remains high); 
bump maps to give definition and form to an otherwise flat 
surface; and masks to combine with any and all of these. And 
all of these effects can be animated. 

Obviously, very few textures will use all of the potential 
variations aval I able to them. Most will only use one or two 
variations, although this still in creases the overall production 




time, especially if there is any reworking of textures. 
Previously, texture changes could be made at any time in the 
production cycle, even late into the beta period. Now with 
each level of complexity added to the texture, the overhead 
required to adjust or rework the texture is multiplied, so that 
instead of changing just one texture, you can end up having 
to rework several. 



Animation at Break-Neck Speed 



With graphics processors capable of manipulating 
geometry at rates greater than 50 million polygons 
per second, games such as Namco's Soul Calibur (shown in 
Figure 5) can boast animation frame rates of 60 frames per 
second and higher. What's so special about 60 FPS? Well, it 
just so happens that 60 FPS is very close to the critical flicker 
frequency (CFF) for normal human vision. When this speed 
is reached, the images on screen stop looking like a sequence 
of frames and start looking likea solid, continuous data 
stream, j ust I i ke the one we get when we look at the world 
around us. 

Steven Schwartz (Visual Perception: A Clinical Orientation, 
1st ed. Norwalk, Conn.: Appleton & Lange, 1994), explains 
the CFF of human visual perception as follows: "Consider a 
light that is pulsing, such as the blinking cursor on a com- 
puter screen. It is easy to discern that the light is blinking 
because of the low frequency, or rate at which it flashes. 
Imagine gradually increasing the frequency. As the light 
blinks faster and faster, it would eventually reach a rate 
where it would no longer be possibleto detect that the 
light isflashing, it would look likea 'solid,' or continuous 
light. We say that our visual system has fused the flicker. 
The frequency at which that occurs is called the critical 
flicker frequency (CFF) or flicker fusion frequency (FFF). 
The CFF for human vision can vary with several environ- 
mental and psychological factors, but in general it varies 
between 50 and 70 FPS." 

What this means to animators is that in animationsof suf- 
ficiently high-fidelity (60 keyframes per second, or lower 
with an effective interpolation system), characters on-screen 
will display a stark, startling reality not seen before in the 
gaming world. Meeting this challenge means generating a 
lot of keyframes, either through procedural methods, 
motion capture, or by sheer, grunting hand-animation. All 



FIGURE 5 . A frame rate of6o FPS, as in Soul Calibur, can 
fool the eye into perceiving a continuous data stream. 
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this translates into a potentially more 
complicated and time-consuming 
process of character animation, further 
increasing the time involved in the 
development process. 

In addition to the basic advances 
which allow us increased capabilities in 
modeling, texturing, and animation, 
there have been significant improve- 
ments which may bring even more 
drastic changes in the way we develop 
content. To engineers, the radically 
increased processor power and avail- 
ability of dedicated geometry proces- 
sors add up to more particles in our 
particle systems, faster and more accu- 
rate colli si on detection, more realistic 
and higher-resolution lighting and 
shadow casting, and the potential for 
trading out the normal polygon ren- 
dering routines for Bezier curves and 
even NURBS surfaces. One of the 
recent rumors swirling around Ninten- 
do's Dolphin platform isthat it will 
support an advanced NURBSrenderer. 
As unlikely as this may seem, consider 
the potential benefits and correspond- 
ing upheaval in the development 
worl d i f ou r real -t i me ch aracters an d 
environments had the smooth -edged 
look and feel of NURBS surfaces. 



Ask Not for Whom the Bell Tolls 

hi leal I this increased capabili- 
ty offers us artists the chance 
to produce games with more flash, 
dazzle, and realism than ever before, 
the price we pay is an across-the-board 
in crease of the time it takes to develop 
the content. A project which two 
years ago may have taken a ten-man 
art team 18 months to develop, could 
easily take the same team 36 months. 
Since publishers are still loatheto go 
beyond a two-year development cycle, 
without significantly changing the 
techniquesweuseto gen erat e co n - 
tent, we will be obliged to add person- 
nel, reduce the scope of our games, or 
both. Considering how hard it isto 
find talented, experienced artists in 
the gaming industry, it's easy to imag- 
ine a situation where the larger pub- 
lishers with the most money begin 
siphoning off all their artists and ani- 
mators to meet the demands of a more 
robust production cycle. This could 
ultimately leave many of the smaller 
development houses out in the cold, 
since they wouldn't have sufficient 
personnel to carry on the develop- 
ment of an A-title. 



In a related side note, the word on 
the street isthat Sony is aggressively 
pursuing development teams experi- 
enced in producing content for the PC. 
This is a sound strategy for two rea- 
sons. First istheobvioustactic that 
Sony wants to snatch up as many 
uncommitted development houses as 
possible to develop exclusively for their 
platform, thus reducing the market 
share and viability of its competitors. 
Second, those developers who have 
developed on the previous generations 
of consoles are used to working within 
the restrictions imposed on them by 
these soon-to-be-outdated platforms. 
Conversely, developers who have been 
working on PC games have been deal- 
ing with a constantly evolving plat- 
form, whose capabilities are at present 
only slightly below that of the next- 
generation hardware. Theoretically 
th en , t h ey are al ready f am i I i ar w i t h t h e 
production levels required to create a 
product on the newer hardware. It will 
be i n teresti n g to see wh eth er th i s strat- 
egy ultimately pays off. 



Wrap Up 

The history of videogames is, of 
course, also the history of the I um- 
bering juggernaut of technology. 
Consumers do their part by dutifully 
soaking up the latest advances in tech- 
nology, but the real burden of the tech- 
nology race will always be shouldered 
by developers. With the imminent 
release of Sony's Playstation 2 and Nin- 
tendo's Dolphin platform lurking 
behind it, developers need to start 
preparing now in order to be ready. The 
tidal wave of technology is looming on 
the horizon, and we can either ride its 
crest or flail about in its wake. 

And th is wraps it up for me as wel I . 
I'll betaking a much needed coupleof 
months off to do some research and 
replenish my creative juices. In the 
interim, id Software's Paul Steed has 
magnanimously agreed to man the 
Artist'sView. I'll see you all again in a 
few months' time, tanned, rested, and 
ready to render. ■ 

Acknowledgements 

Special thanks to Louise Smith, Vince 
Desi, Wyeth Ridgeway, Dave Coathupe, 
and Stuart Denman. 



w 



GAME DEVELOPER SEPTEMBER 1999 



http://w WW. gdmag.com 



b If O m I <f R a It m a f 



HARD TARGETS 



Matrox: Rolling with the Punches 
and Coming out Swinging 

The graphics industry has a few old veterans, battle-scarred and a little 
weary, but one company continues to defy the aging process, and seems to 
be growing in strength. Matrox, a Canadian company founded in 1976, is 
still one of the leading brands in the business. It must be said that 1998 



was a tough year for M atrox, a ti me 
when it had dropped off most game 
developers' radars as a hot technology 
company. I guess everyone was too 
busy with 3dfx and Nvidia, and then 
along came S3 to don the mantle of 
comeback kid. So, having sat in the 
pole position in the 2D graphics arena, 
Matrox seemed an al most-ran in the 
era of high -performance 3D graphics, 
driven as it is by the gaming communi- 
ty. Now, with theG400, a product that 
sits more comfortably in the worlds of 
both 2D and 3D performance graphics, 
M atrox has shown itself to be a peren- 
nial favorite of reviewers and con- 
sumers. The secret to M atrox's success 
cannot be easily explained, and isoften 
shrouded in mystery, even to those in 
the industry that have known the com- 
pany for all its years. 



The Backgrounder 

Matrox I i kes to be i n the back- 
ground. It is secretive and 
unapologetic. It is focused completely 
on its customers and products. It 
shouldn't be any mystery why the 
company is successful, but it's unusual 
for any graphics company to continue 
to ride new product cycles and remain 
with the leaders. The graphics busi- 
ness is supposed to keep knocking its 
winners off their pedestals, and the 
amount of investment required to 
compete in the modern world of high- 
ly complex 3D circuitry should be 
enough to bar all but a handful of 
heavily financed players. But Matrox 
remains insular, and less vain than its 
competitors. 



M atrox was born as M atrox Elec- 
tronic Systems, based in Montreal, 
Quebec. The company has always 
been privately held, and as a result, it 
has been subject to all kinds of specu- 
lation from its competitors. Initially, 
that didn't matter. Matrox made its 
money supplying multi-display sub- 
systems to Wall Street traders, and 
stayed below the radar of other graph- 
ics companies more interested in the 
drawing power of CAD. It wasn't until 
the 1980s that Matrox got into sup- 
plying CAD graphics accelerators, but 
even then Matrox was eclipsed by big- 
ger companies ranging from Video 
Seven and Hercules to, eventually, 
ATI, the other Canadian graphics 
company of note. 

The company won a $100 million 
contract to supply the U.S. Army with 
a video disk training system in 1986. 
For many years, M atrox's competitors 
assumed that it was this single con- 
tract that kept the company afloat, 
and allowed it to build up its expertise 
in the PC graphics arena. Of course, 
there is no way of knowing the truth 
behind such rumors, but had Matrox 
not come out with the MGA chipset 
and Millennium graphics boards in 
1993, they would have been unlikely 
to continue in the graphics business. 
In fact, in 1994, when the company 
established Matrox Graphics Inc. as an 
independent company, it was partly 
gambling on the success of the M illen- 
nium, and partly protecting itself from 



the vagaries of a graphics market that 
had decimated many of its pioneers. 

Having dealt with the company as 
both a competitor in Europe and as an 
analyst, I assume that most of 
M atrox's success has come from a 
built-in confidence and determination, 
exemplified by people such as Lome 
Trottier, Matrox Graphics' president 
and one of its cofounders. This may be 
part of the M atrox mysti que as wel I , 
that the company receives an influx of 
young talent from local technical col- 
leges, and senior management instills 
enthusiasm for Matrox and its prod- 
ucts in the minds of a smart, young set 
of employees who aren't tempted the 
way thei r counterparts are i n Si I i con 
Valley; Matrox is a high-tech haven 
and breeding ground for its own 
biggest fans. To this day, I continue to 
be amazed by the strength of convic- 
tion among ordinary Matrox employ- 
ees, and this element is as important 
to M atrox's success as its products. 



Getting Sex Appeal 

Still, all theOEM presence and dis- 
tribution channels in the world 
have done little to enhance Matrox's 
reputation in a consumer market that 
is highly influenced by game develop- 
ers. That may all change with the 
G400, which is aimed specifically at 
improving Matrox's retail awareness, 
and restoring some sex appeal to the 



Omid Rahmat is the proprietor of Doodah Marketing, a digital media consulting 
firm. He also publishes research and market analysis notes on his web site at 
http://www.smokezine.com. He can be reached via e-mail at omid@compuserve.com. 
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CHART 1 . Matrox Graphics' revenues, in millions of U.S. dollars. (Source: com- 
pany press releases.) 



brand. Matrox's 2D performance 
remained unchallenged for many 
years, but in the 3D arena the compa- 
ny has been sorely lacking in any sig- 
nificant technology or market posi- 
tion, despite having an incredible 
pedigree in developing 3D drivers and 
h ard ware si n ce th e 1980s. Th e resu I ts 
of Matrox's lack of 3D sex appeal is 
reflected in the big revenue hit the 
company's graph i cs busi ness took i n 
1998, as shown in Chart 1. 

O.K., so the figures are from a pri- 
vate company's press releases, but 
they're probably not too far off the 
mark. The Matrox folks keep their 
cards close to their chest, but they also 
tend to be quite honest when they do 
share information. Although Matrox 
continued to maintain most of its 
market share and unit sales in 1998, it 
took a big hit on the selling price of 
its chips because it didn't have a per- 
formance graphics part to compete 
with the likes of Nvidia, or 3dfx. 
Furthermore, Matrox was suffering 
from a squeeze on profit margins 
brought on by I ntel 's entry i nto 
graphics in 1997, a situation that 
resulted in almost every other graph- 
ics vendor taking a hit on pricing as 
well. Only 3dfx escaped the worst 
impact of the pricing pressures of 
1998, and the gaming community 
became the focal point of all the 
graphics vendors. Matrox just didn't 
have enough to offer at the time. 

Back on Track 

However, the G400 gives M atrox a 
unique position in the perfor- 
mance graphics market of 1999 — 
namely, environmental bump map- 
ping in hardware. Of course, Matrox 
has also gone back to its roots in 
multi-screens, and provides a dual- 
screen output from asingleG400 
board. The dual -screen feature is not 
unique to Matrox (Diamond has had 
it availableon its high-end FireGL 
boards for a number of years), but 
Matrox is providing this feature on 
what is, in effect, a consumer, game- 
enthusiast product. And, as if Matrox 
wanted to confirm that it understands 
the new world of graphics, the G 400 
hits all the usual specification points 
for performance 3D: lthasAGP2X 
and 4X support, a 32-bit rendering 



pipeline, a 32M B memory load, and 
an 8-bit stencil buffer, with a dash of 
DVD video playback acceleration 
thrown in for good measure. 

Then there are the usual flourishes 
by M atrox; the company has always 
added a wealth of software and utili- 
ties to its retail products, and with the 
G400 you get a M atrox software DVD 
player, MicroGrafx Simply 3D 3 and 
Picture Publisher 8, PointCast Net- 
work and Expendable from Rage Soft- 
ware, which, naturally, showcases the 
bump mapping capabilities of the 
board. However, even morecom- 
mendably, Matrox has stepped up its 
online support and game oriented 
information sections of its web site. 
M atrox is as good as any of its com- 
petitors at developer relations, 
although the company continues to 
lag behind ATI, Nvidia, S3 and most 
definitely 3dfx in the consumer mar- 
keting stakes. With the G 400, there 
seems to be a change of emphasis on 
the part of the company; gone are the 
days when Matrox preached to game 
players and developers to makeup for 
its shortcomings, replaced by a clear- 
cut message that the company now 
gets gaming. 

The game section of the company's 
web site is not the sexiest of the hard- 
ware vendors' 3D gaming sites, but it's 
practical and comprehensive, reaching 
the casual gamers who are most likely 
to be interested in the company's 
products. It's as efficient and unam- 
biguous as anything else you'd see 



coming out of Matrox. Perhaps the 
word I am searching for is profession- 
al, but with oomph. 

Epilogue 

In the past year M atrox has success- 
ful ly transformed itself, and had a 
drink from the fountain of youth. 
Whereas in 1998 the market was con- 
tent to keep M atrox in the back- 
ground, today Matrox is looking like 
an aggressive player: It has well 
reviewed and well received products; it 
has established its credibility in the 
gaming market with theG400 in a 
very short space of time; it is covering 
its traditional OEM and system inte- 
grator markets as wel I as ever, while 
leveraging a higher consumer profile 
with the G400's unique features. 

In addition, under the surface, 
Matrox has reorganized its manufac- 
turing operationsto take advantage of 
better pricing in Asia, and is courting 
the Taiwanese motherboard makers to 
increase its market share in the PC 
graphics chip business. The company 
looks less and less like the Matrox 
graphics board company of Millenni- 
um days, and more I ike a competitor 
to ATI, Nvidia, S3, and 3dfx, just as it 
should be. Now there are five strong 
brands in the graphics business. 
Matrox's timing couldn't be better 
because around the corner, waiting to 
spoil the show again, is Intel. This 
time, Matrox is ready. ■ 
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■jPj n a relatively short period of time, videogame art has gone from 
I thesingle white blocksfound in Pong to thousands of colors 
J ^ wrapped around thousands of polygons. This in turn has 
allowed the worlds in games to evolve from a single black screen to 
immense 3D worlds. For those of us who find ourselves in the lucky 
position of being game artists, the trick is to find ways to leverage this 
cache of materials and palettes to create powerful, realistic worlds that 
draw in players. How does one do that? By educating yourself about 
theelementsof color and production design and applying these 
lessons to your games, you can focus the player's emotion within a 
world, aswedid at Insomniac Games in our recent Playstation title, 
Spyro the Dragon. In addition to color theory, Spyro's production 
design is explored by Insomniac Games artist John Fiorito (seep. 42). 
The Difficulty of Color Consider the exam pie of the traditional painter. 
Subject matter, design, composition, and color must all be balanced 
togetherfor the pain ting to come alive. Now take the example to the 
next level: A movie director or cinematographer has the same issues 
as the painter, plus the added complexities of motion, changing 

After finishing a degreein Art Education fronn San Jose State, CraigStitt started making videogames for 
Sega in 1991. W liileat Sega, lieworl<ed creating 2D textures and animations on Genesis title's Km 
Chameleon, Sonic 2, and Sonic Spinball. In 1996, Craig joined Insomniac Games and began creating 
both 2D and 3D art for Insomniac's debut title, Disruptor, followed by their hit title, Spyro the Dragon. 
He, and everybody else at Insomniac, is currently busy working on the soon -to- be- released Spyro 2. Visit 
Insomniac Games' web siteat www.insomniacgames.com. 
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perspectives, and tinning. In games, we face the challenge of 
making a movie in which the viewer can go anywhere and 
do anything whenever he or she wants. Our "viewers" can 
see our world from any distance or perspective anytime they 
want. How much harder does that makeour jobs? We not 
only have to worry about what is in front of the "camera," 
or more precisely, in front of the player, but what is behind, 
below, above, and all around him or her, in real time — and 
it has to be fun to boot (see Figure 1). 

One cornerstone of traditional art and great games is the 
careful use of color. What makes getting color "just right" so 
complicated isthefact that color has a powerful effect on 
our senses, and we're also very sensitive to subtle color 
changes. A littletoo much blue in a scene, and the mood of 
the whole world changes. Fortunately, there are a couple of 
techniques that can make the process of coloring a game 
world more manageable. 



A Gallery of Worlds and Emotions 




nee your basic game design has been completed, as an 
artist or level designer you ought to start thinking 



about specific ways that the world you are creating will draw 
the player in. Which emotions will your world or your level 
need in order to draw players in and entice them to stay? 
When selecting a level's color palette, you're also making a 
decision about the underlying emotion that the level will 
convey to the player. 



I have found that it helps for me to think of the game as a 
gallery of paintings. In a gallery, each painting must stand 
by itself, yet it should also support and strengthen those 
paintings around it. This happens only if each painting in 
the gallery is balanced; each painting has been placed with 
complementary paintings which have been thoughtfully 
selected, and carefully arranged and lit. So it must be with 
the art and colors in a game. Each level's colors and textures 
should be chosen to support and strengthen not just the 
level itself, but the whole game. 



Brood Strokes of Color 

I I ike to work in broad strokes of color, picking two or 
three colors that will be the foundation forthecolor 
design for each individual level. It's important to ask your- 
self, what emotions do I want to evoke in players when they 
first step out onto theplayingfield?Thecolor palette you 
choose will naturally depend on the nature of the terrain, 
the architecture of buildings, time of day, and the effects of 
weather. However, if you're trying to evoke a particular emo- 
tion as well, you'll have to takethat into account. Do you 
want to fill the player with awe and wonder, or fear and tur- 
moil? Do you want them to feel comfortable and at home, 
or unsettled and far from home? Once the core emotions are 
laid out for each level, decide which colors best elicit those 
emotions from the player and also work well with the other 
level elements (terrain, architecture, and so on). 
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FIGURE 1 . An artist's job is complicated by the fact that in the 3D worlds, players can now see everything from everywhere. 



Consider how each of the various characters within the 
game will fit into your color scheme. For Spyro the Dragon 
(a character-based platform game with a cast of dragons set 
in a medieval fantasy world), we made Spyro green in the 
earliest stages. But we quickly discovered that this didn't 
work with many of our primarily green environments — 
Spyro kept disappearing into the environment. We experi- 
mented with over a dozen different colors for Spyro before 
we finally found onethat satisfied all our concerns: purple. 
As purple, Spyro didn't disappear into the grass on many 
levels, he was no longer the same color as several of our 
competitors' characters, thedetail in his textures stood out, 
and he was a bright, fun character. 

These same questions had to be asked for each and every 
object and creature in Spyro's world. It also was important 
for game objects. For example, a great amount of treasure 
has to be found and collected in Spyro, so it was important 
that players could easily identify treasure at great distances. 



We made this easier by applying motion and a little animat- 
ed sparkle to the gems to make sure they were always the 
brightest thing around. 

A level's core palette should contain only two or three 
base colors. Using these base colors, a level's detail is then 
defined using various shades and values along with small 
amounts of complimentary or contrasting colors. Be careful 
when extending this core palette because using too many 
colors can lessen the impact of any one color and you end 
up with emotional mud — just as if you mixed too many 
different colors of paint together. A variation to this rule is 
that some worlds may have multiple, distinct palettes, one 
for each area found within that world. For example, one 
palette for insidea building versusoutside it. Even in these 
cases though, each of these distinct palettes should be limit- 
ed to two or three colors, and there will still be one master 
palette, of two or three colors, which sets the tone for the 
entire world. 
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FIGURE 3 . By experimenting witli different s/c/es, tlie 
nature and emotion of an entire world can be radically 
altered. 
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FIGURE 2 . During ttie development ofSPYRO, a wtiite board 
was used to display all 30 levels and their respective colors. 
It went through many changes before the end of the project. 



Oneway to check the overall state of your "gallery" — the 
color continuity between game levels — is to view screen- 
shots or test swatches from each of the levels side by side, as 
if they were a color wheel or contiguous screen shots in a 
consumer game magazine. Decide if each individual level's 
look supports and strengthens the others. If not, rework the 
colors in one or more of the levels. More often than not, it 
doesn't take much of a change to find that balance if you 
catch the problem early. With Spyro, as soon as we had a 
rough design document with its specified worlds, we put up 
a whiteboard in the art room with a brief description of the 
sky and the core palette for each of the levels. Further along 
in the development process, small color print outs of screen- 
shots augmented the white board (see Figure 2). 



The Power of the Sky 

If your game takes place outdoors, one of the dominant 
colors in the master palette will be that of the sky. Time 
and time again at Insomniac wehavebeen surprised at the 
tremendous i mpact that the color and nature of the sky has 
on a world. Many times when we had a difficult time getting 
the right emotional impact from a Spyro level, someone 
would suggest that we try a different sky. Every time we were 
surprised at the extent of the change brought to the level by 
the new sky. We learned that unearthly colors in a sky can 
create unexpected emotions, which is sometimes good if you 
want to maketheplayer uncomfortable (as if he's in an alien 
environment), but if that's not your goal, use caution when 
dealing with sky colors (see Figure 3). 

Recently, I designed a sky that was one of my all-time 
favorites. It was a misty green sky, filled with wispy clouds 
and distant planets. It complemented the world it was 
designed for, but something wasn't right. While beautiful, it 



also evoked negative reactions from people. Finally someone 
pointed out that it looked poisonous. That would have been 
great if that was what we intended, but this particular world 
wasn't supposed to be poisonous; threatening yes, but not 
poisonous. In theend, we went with a more naturally-col- 
ored night sky, which contained several moons and a haunt- 
ing red glow on the horizon. 

Consider the relative contrast between a world and its sky, 
and the differences in their color saturation. If the terrain is 
bright and saturated, then often it'shelpful to color thesky 
using softer, desaturated colors. The reverse is also true. This 
helps set off the horizon against the skyline, which in turn 
gives the player some depth cues and aids navigation. When 
the terrain and sky are too similar in color or saturation, 
they lack the necessary contrast and appear to flatten out. 
Definition gets lost, and players often do as well. 



Wallpapering Worlds 

At Insomniac, we try to keep both the contrast and the 
color saturation down and still keep colors bright in 
our textures. Typically televisions, especially NTSC-based 
ones, pump up both the contrast and saturation of gamecol- 
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ors, pushing the images over the top into acartoonish look. 
Sometimes that's the goal of the game developers, but more 
often then not, a slightly softer, more realistic look is better, 
even on a cute or light-hearted game. 
Shading AND Lighting The final major source of color comes 
from shaded textures, from techniques such as colored ver- 
tex shading. The addition of colored shading on top of rich 
textures can create a spectacular look, but sometimes it can 
be too rich. The problem is that the cumulative effect of col- 
ored vertex shading can over-saturate or intensify the con- 
trast of texture colors. This is one more reason to keep the 
base textures somewhat desaturated — there is plenty of 
room to apply color shaders with out blowing the colors 
over the top (see Figure 4). 



Where Am I, Where is it Safe to Stand? 

The two practical aspectsof videogame art show the play- 
er where it is safe or unsafe to travel, and to give him 
visual landmarks so that he doesn't spend too much of his 
time wandering around lost and confused. 

Th e si m p I est way to sh o w t h e p I ay er safe areas to wal k i s by 
defining edges. It'sa timeconsumingtask, but makingsure 
that a real-time strategy game, for instance, has terrain with 
carefully highlighted nooks and crannies will add reality to 
the game and alleviate much of the frustration a player is 
bound to feel if he keeps getting killed because he inadver- 
tently walks off cliffs, into quicksand, and so on. Sometimes 
edge definition requires a not-so-subtle value or color varia- 
tion to properly indicatetheedgesof a walkway or wherea 
ledge exists on the far side of a canyon. Proper texture design 
can also help define edges and boundaries. 

Creating navigational landmarks can behelped by careful 
level design, but it also depends upon careful coloring. 
Sometimes it'sthecase of simply color coding similar look- 
ing objects so the player can differentiate between them. 
Sometimes it is difficult, when "I and marking" an area, to set 
aside the desire to create a truly realistic environment. There 
may not be a good reason why one section of the wall is col- 
ored differently from the rest, or why one cave would emit a 
blue light and another cave had a red light, but the player 
won't care about that nearly as much as they will ifthecaves 
aren't color coded and they repeatedly get lost because the 
caves look alike (see Figure 5). 



Ageless Principles 

Overseeing the color management within any game is 
an ongoing process. One of the most important things 
to do during development isto regularly take a step back 
and view the game as a whole. Examineeach level and make 
sure that it works on its own and also supports the overall 
gestalt of the game. The textures and shaders should 
strengthen the settings, the settings should strengthen the 
game play, and the player, at a glance, should be able to see 
what's important what's simply eye candy. It's constantly a 
surprise to me, and everyone here at Insomniac, how power- 
ful a role color plays in pulling all these elements together, 
or in tearing them apart. 
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FIGURE 4 . Top: A model with only simple vertex sfiading 
and no bacl<ground s/cy. (Note the use of the different col- 
ored shaders on the island, bridge, and tunnel.) Middle: The 
same model with shading and the s/cy in place (Note how 
the color of the s/cy is reflected in the use of color in the 
shaders.) Bottom: The finished world with models, shaders, 
textures, and s/cy. 




FIGURE 5 . Using color to differentiate or "landmarl<" areas 
can prevent players from getting too lost or confused. 



Take advantage of the lessons learned from the traditional 
schools of art. Basics such as color theory, balance and com- 
position are ageless, and we must understand them and keep 
our creative edge sharp by usingthem. It isall too easy to get 
caught up in tilecountsand polygon limits, and missthefact 
t h at a I evel i s I i f el ess o r co n f u si n g becau se we f ai I ed to sh o w 
adequate respect for the power of basic artistic concepts. 
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Spyro Production Design 



BV JOHN FIORITO 



F 



or the Playstation title 
Spyro the Dragon, 
Insomniac Games 
faced th e ch al I en ge of 
creating a unique look for a new 
game. The production design 
needed to be strong and consis- 
tent enough to endure a year- 
and-a-half development sched- 
ule, yet even more significant 
was the need to set Spyro apart 
from an already crowded field of 
platform games and various 
titles that involved dragons and 
medieval worlds. To do this, our 
team established and followed a 
rigorous set of production 
design guidelines whilemaking 
the game. 

Our goal was to make Spyro 
THE Dragon visually unique, 
coherent, and memorable. Well 
before starting production we 
developed a set of artistic guide- 
lines that we came to know as 
our "production design bible." Our 
basi c ru I es were as f 1 1 o ws. 
Use bright, saturated colors. We felt 
that too many games, especially 3D 
games, achieved their look of realism 
by using muted color palettes which 
favored gray, brown, and black. By 
applying bright, vivid color schemes 
throughout Spyro the Dragon, we 
would stand out from the start. 
Leverage the look of Camelot and fairy 
TALES. While there were many games 
set in medieval and fantasy worlds, 
most seemed to favor a darker more 
serious "Dungeons and Dragons" 
look. To complement our use of satu- 
rated colors, we pursued a lighter 
medieval style, closer to Camelot 
than to D&D. 

Characters should complement the envi- 
ronments. Spyro was going to be a 
character- based game, and much of 
its personality came from its anima- 
tion. Therefore it was necessary to 
make the characters stand out 
from the environment while 
maintaining our fantasy theme. 
Often much of a character's 
body was gouraud shaded which 
allowed its design and move- 
ment to stand out to the player. 




FIGURE 6 . Insomniac Games* production design for Spyro the Dragon created a dis- 
tinctive lool< for a new character and game. Spyro's medieval fantasy world was com- 
posed with bright colors, soft decorative textures, and a cast of fairy tale characters. 



By keeping the colors of the charac- 
ters bright, we further emphasized 
their appearance while maintaining 
our global color palette. 
Use soft textures and simple decorative 
MOTIFS. Our early tests showed that 
the PlayStation's display sharpened 
textures to the point where highly 
detailed artwork degenerated into 
distracting visual noise. By avoiding 
hard outlines, high contrast, and too 
much detail in individual tiles, we 
were able to create a soft atmospher- 
ic quality which was aesthetically 
pleasing, yet not distracting to game 
play. 

These basic rules formed the foun- 
dation of the game's appearance and 
helped us achieve visual consistency 
throughout the title. With these rules 
established and understood by our 
entire team, there was little room for 
miscommunication or confusion 
since we had established a look and 



a definitive way of qualifying it. 
(Figure 6). 

Spyro's universe comprises six dis- 
tinct worlds, dozens of animated 
characters, bonus flying rounds, a 
secret level, and introductory and win 
sequences. With so many characters 
and locations, adhering to our pro- 
duction design was essential. Yet at 
the same time we needed to give each 
world as distinct a look as possible 
without straying from our basic 
design rules. One of our solutions was 
to design extreme variation into the 
game's environments. Spyro begins 
his adventure in a castle garden and 
proceeds through a desert, snowy 
mountain peaks, a swamp, dream- 
scape, and finishes in a mechanical 
world. Furthermore, theflying rounds 
are made of gl owi n g crystal s. Fi n al I y , 
to differentiate each world even more, 
we designed a dramatic three-dimen- 
sional panorama at the start of each 



John Fiorito is an artist at Insomniac Games where he creates wireframe models, textures, 
and conceptual sketches for Spyro the Dragon. He received degrees in architecture from 
the University of California, Berkeley, CA and illustration from Art Center Col lege of 
Design, Pasadena, CA. Contact him via e-mail atjwf@insomniac.unistudios.com. 
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world to givetheplayer a memorable 
first impression (Figure?). 

Within each of these worlds there 
were th ree I evel s of game pi ay, a boss 
round, and a central navigational 
hub. Again, we faced the production 
design challenge of giving each level 
an individual look while maintaining 
a con si sten cy to th e overal I worl d . 
Our first method was to vary the 
locations and geography of a level. 
For instance, in the desert (or 
"Peacekeeper") world, the settings 
in dude a fortress, pueblo village, ice 
cavern, and volcanic crater (Figure 8). 
Wealso created unique looks within a 
level by depicting varied and dramat- 
ic times of day. In the Artisan world, 
the levels occurred at daybreak, mid- 
afternoon, sunset, and under a full 
moon. 

In Spyro's worlds we developed a 
series of visual motifs that empha- 
sized the connection between them. 
One such motif was a member of a 
family of ballooniststhat Spyro had 
to hi re to travel from world to world 
— so seeingoneof theseballoonists 
i n d i cated th e way ou t of th e I evel . 
Likewise, within a world, a system of 
portals gave access to each of the lev- 
els and each portal was styled to fit its 
world. Similarly, the architecture 
within each world maintained 
consistent design sensibilities which 
included flared bases, crenellated tur- 
rets, and decorative buttresses. For 
added variety, we sometimes located 
rival civilizations in a level, which 
allowed us to display thecontrasting 




FIGURE 7. To give each of Spyro's six worlds a unique first impression, we 
often employed a dramatic ttiree dimensional panorama. Ttiis opening scene of 
the Magic Crafters world established its basic characteristics and created a 
memorable view. 



stylesof the indigenous and invading 
characters and their architecture. 
Regardless of a level's theme, each 
one shared the same amount of orna- 
mentation, and this gave each level a 
rich appearance. 

Some of our greatest production 
design challenges arose within the 
levels themselves. In these massive, 
free-roaming, 3D environments, it 
was very easy for a player to become 
disoriented and lost. Just finding a 
level's exit often proved difficult. 
Search i n g f or th at I ast pi ece of trea- 
sure or completing a spatially-orient- 



ed puzzlecould be especially taxing. 
Getting lost could even prove fatal in 
any of our timed flying rounds. To 
prevent players from getting too frus- 
trated we needed to supplement our 
production design rules with a series 
of visual solutions that kept the navi- 
gation of a level as straightforward as 
possible. Here are thesupplemental 
design rules we created. 
Use landmarks whenever possible. A 
landmark is a unique structure or 
geographical feature that distin- 
guishes one area from another, 
which gives the player a reference 




FIGURE 8 . Different settings, climates, and times of day added variety to Spyro's levels while adhering to the overall pro- 
duction design. Here, in the Peacel<eeper world, locations include a pueblo village at sunset, an ice cavern at night, and a 
desert fortress at midday. 
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point in the level. 
Specific pieces of 
architecture, such as 
bridges, castles, 
fortresses, or other 
buildings that had a 
strong presence and 
appeared only once 
in a particular level 
proved to be the most 
effective landmarks 
(Figure 9). To 
enhance the unique- 
ness of a landmark, 
we added specific nat- 
ural features around 
it, such as waterfalls, 
rivers, rock forma- 
tions, or trees. 

Create gateways and checkpoints. To 

indicate that a player was making 
progress in a level, we tried visually to 
emphasize the transition between 
specific areas. This could be as funda- 
mental as entering a castle gate or 
crossing a bridge, or as subtle as 
adding more snow on the ground to 
indicate higher elevations within the 




FIGURE 9 . Specific pieces ofarctiitecture proved to be one ofttie most effective ways of creating 
a landmarl<. From initial concept to the finished play field, we designed unique areas into the 
game to help players maintain their bearings. 



level. These transitions would often 
occur after passing through a narrow 
corridor or completing a long glide, 
and they served as memorable focal 
points in a level. 

Balance interior and exterior spaces. We 

found that a variety of interior rooms 
and exterior spaces throughout a level 
provided a player with strong visual 



references. It also gave us the oppor- 
tunity to create unique geometry. By 
placing a cavern between two valleys, 
for example, we not only defined dif- 
ferent zones of game play, we were 
also ableto change the look of the 
environment markedly and naturally. 
An d by vary i n g th e types of spaces 
using caves, halls, valleys, or court- 
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FIGURE 10. l/l/e found that solving a visual problem on paper 
was much faster than using a computer. Modifications to an 
area during the design phase could be completed in a matter of 
hours instead of the days or even weel<s it tool< to implement 
the finished design on the computer. 



yards, we were ableto create numerous unique locations 
throughout a level. 

Change SCENERY LIGHTING. Varying the lighting in different 
areas of a level created environments that were dramatical- 
ly different. We lit interiors in a variety of ways, including 
natural light, fire and torch light, and any number of col- 
ored, glowing light sources. This helped players get their 
bearings, and also gave us added aesthetic opportunities 
throughout a level. Outdoor lighting varied as well. For 
instance, where a mountain divided two valleys, one side 
might be sunlit whiletheother lay in shade. Narrow 
spaces such ascanyonsallowed us to create strong shad- 
ows, while open places contained bright areas of sunlight. 

In addition to our visual choices, a number of technical 
and game-play elements influenced our production 
design. Since Insomniac'sgameenginefor Spyro did not 
use fogging to reduce the on-screen polygon count, many 
areas of the game were designed to hide large portions of 
geometry in the distance. Wherever possible, the world 
had to be built in solid, continuous masses, such as moun- 
tain ranges, castle walls, cliffs, and buildings. Artistically, 
we were careful not to build monolithic fortresses, walls, 
or cliffs which dwarfed Spyro. Where we needed excep- 
tionally large sections of geometry, we tried to reduce its 
scale by varying the surface with unique textures, buttress- 
es, or decoration. Fortunately, and not coincidentally, our 
decorative approach, fairy tale theme, and softened tex- 
tures also reduced the scale of Spy ro's world. 

Spyro's ability to glide great distances forced us to 
design areas that would contain him, yet not feel 
enclosed. This meant that most of our worlds had a hori- 
zontal orientation and simultaneously needed boundaries 
to halt his free- roaming nature. Wherever possible, we 
sought to vary the limits of the worlds. In addition to 
walls, we employed bodies of water, cliff tops, or infinite 
drops to define our outer edges — the more boundaries in 
a level the better. 

Our team soon learned that time was one of the biggest 
limitations in creating Spyro's look. In every instance we 
needed to streamlineour production processes. We relied 
heavily on sketches and diagrams in our production 
design, because solving a visual problem on paper was 
much faster than using a computer. Often, a series of pre- 
liminary studies could be created in a matter of hours, 
instead of the days or even weeks it might take to imple- 
ment onefinished design on the computer (Figure 10). 

Ultimately, the production design methods we used to 
create Spyro the Dragon were as much common sense as 
inspiration. We discovered, however, that defining them 
as rules or guidelines aided and quickened our production 
process. Our framework of visual motifs resulted in effi- 
cient development as well as consistent presentation. 
While we were always short of time, we used our produc- 
tion design to streamline the creation of finished artwork. 
Not only did the production design support thetechnolo- 
gy and game design, it also unified the playing experience. 
Players of Spyro were rewarded with a game that was visu- 
ally logical, possessed artistic continuity, and in the end 
was memorable. ■ 
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his article is not a how-to guide, it's a brain dump 



from the perspective of the engine programmer (me) 



of Shiny's upcoming title, Messiah. Usually Game 



Developer articles are littered with formulas, graphs, and 



code I i sti n gs th at serve to u p th e i n tel I ectual profi I e of th e 



piece. However, I'm not a mathematician and I don't feel 



the need to state any information in the form of a graph 
— in this article I describe problems, solutions, and 



things I've learned in general terms, and that allows me 



to cover a lot more ground. 



My interest in character systems 



started more than four 



years ago, when I 




was working at 



Scavenger, a now- 



defunct development 



studio. I was assigned to 



develop a "next-generation" 



I 

■D 



■D 



Men gamefor the Sega Saturn. 



Sega wanted motion -captured characters and chose to use 



pre-rendered sprites to represent them. I observed the 
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planning of the motion -capture ses- 
sions, examined the raw mo-cap data 
that these sessions generated, saw it 
applied to high-resolution characters 
on SGI s, and then received the frames 
which I was to integrate into thegame. 

The results were disappointing. The 
motion-capture data, which could have 
driven characters at 60 frames per sec- 
ond (FPS), was reduced to little bursts 
of looping animation running atl2 to 
15 FPS, and could only be seen from 
four angles at most. The characters 
were reduced to only 80 to 100 pixels 
high, and still I still had problemsfit- 
tingthem in memory. The models we 
spent weeks creati ng came out as fuzzy, 
blurry sprites. 

Around that time, two new model- 
ers, Darran and M ike, were hired for 
my team (and the three of us still work 
together at Shiny). These two talented 
modelers wanted to create the best- 
looking characters possible, but we 
didn't know how to justify the time 
spent on modeling super-sharp charac- 
ters when the resulting sprites came 
out looking average at best. 

Eventually, Sega Software stopped 
developing first-party games and 
X-Men was canned. Soon thereafter we 
were asked to develop our own game. 
That provided me with the incentive to 
figure out how to represent characters 
in a game better. We knew we wanted 
at least ten or more characters on the 
screen simultaneously, but all the low- 
resolution polygonal characters we had 
seen just didn't cut it. So I decided to 
keep pursuing a solution based on 
what I had been working on forX- 
Men, hoping that I'd comeup with 
something that would eventually yield 
better results. 

At first I flirted with a voxel -I ike solu- 
tion, and developed a character system 
which was shown at E3 in 1996 in a 
game called Terminus. Thissystem 
allowed a player to see characters from 
any angle rotating around one axis, 
which solved a basic problem inherent 
to sprite-based systems. Still, you 
couldn't see the character from any 
angle, and while everybody liked the 
look of the "sprite from any angle" 
solution, many people wanted to get a 
closer look at the characters' faces. This 
caused the whole voxel idea to fall 
apart. Any attempt to zoom in on char- 
acters made the lack of detail in the 
voxel routine obvious to people, and 



the computation time shot up (just try 
to get a character close-up in West- 
wood's Blade Runner and you'll see 
what I mean). I tried a million different 
ways to fix the detail problem, but I 
was never satisfied. The other problem 
with a voxel-based engine was the 
absence of a real-time skeletal deforma- 
tion system. Rotating every visible 
point on the surface of a character in 
relation to a bone beneath the surface 
was not a viable solution, so we had to 
pre-store frames and again, as in X- 
Men, cut down in the playback speed 
and resolution. At that point I was 
ready to try a different solution. 

When my team and I were hired by 
Shiny a little less than two-and-a-half 
years ago, I had done the prototype of 
a new character system after leaving 
Scavenger. Shiny was really excited 
about it and I continued to develop the 
system for the game that would even- 
tually become Messiah. Let's look at 
that system and examine the solutions 
I came up with. 



System Goals 

There were a number of goals for 
the new M essiah character anima- 
tion system. The first was to put as few 
limitations as possible on our artists. 
Telling Darran to do his best in 600 
polygons would surely kill his creativi- 
ty. At the very least, it was an excuse to 
create only so-so characters. At that 
time for PC games, the polygon count 
for real -time animated characters was 
around 400 each, and Tomb Raider 
topped the scale at about 600 to 800 
polygons per character. My fear was 
that this number was going to change 
significantly during thetime it would 
take to develop M essiah, and apparent- 
ly I was right in that assumption. 

Another problem I wanted to solve 
was the need for our artists to create a 
low-resolution version of a character 
for thegame, a higher resolution for 
in-gamecutscenes, and a high-resolu- 
tion version for the pre-game cinemat- 
ics and game advertisements. Why, I 
thought, should we have to do all this 
extra work? I wanted the artists to have 
no excuse for creating mediocre mod- 
els, and I wanted to eliminate their 
duplicitous work. 

Whatever system I created had to be 
console-friendly. My two targets at that 



point were the Sony Playstation and 
Sega Saturn. Both had a limited 
amount of memory — in Sony's case, 
only IK of fast RAM . So it was impor- 
tant that the system could perform 
iterative steps to generate, transform, 
and draw the model. 

Finally, I was convinced that curved 
surfaces would rule supreme in a few 
years time, so I wanted to make sure 
my system had that aspect covered. 

I liked the visual results of my limit- 
ed-resolution voxel model, and decid- 
ed to make that my quality reference. 
The no-limit-on-the-artist modeling 
method seemed to work, so we stuck 
with that. Thissystem supported auto- 
matic internal polygon removal, and 
using it Darran was able to dress the 
characters like Barbie dolls: he could 
stick buttons on top of the clothing, 
or model an eyeball and move it 
around without having to attach it to 
the eyelid. Clothing looked great, 
since all wrinkles were created using 
displacement mapping. Clothing 
shadows and light variations looked 
just right. In fact, most characters in 
M ESSIAH now average 300,000 to 
500,000 polygons to make the most of 
the system. 

After a bit of back and forth, I decid- 
ed to develop a system that fits patch- 
meshes as closely as possible to the 
body, and then generates the texture 
by projecting the original model onto 
the patch -mesh. To accomplish that, 
the following steps were necessary: 

1. SI ice and render a volume repre- 
sentation of the model with all of 
the internal geometry removed. 

2. Connect the volume pixels into 
strings of data so it's apparent 
what is connected to what. 

3. Apply bone influences. 

Z|. Separate the body into suitable 
pieces, so a patch surface can be 
fitted around it. 

5. Unify the body parts. 

6. Generate a special mesh that goes 
between the separate patch pieces. 

7. Prioritize the unified points. 
Of course, somewhere in this 

process, I also had to figure out how to 
get the skeleton attached to the model. 
Step 1. Rendering the volume model, 

REMOVING INTERNAL GEOMETRY. The firSt 

Step is to cut up a model into a prede- 
fined number of horizontal slices. This 
determines the resolution of the ren- 
dering. A reasonable number is 400 
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FIGURE 1. This is how the data looks 
after volume rendering is completed. 
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FIGURE 2. Here is an example of 
how the bone influence is done on the 
upper torso. 
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slices for models we're testing, and 
1,000 to 1,500 for final models. 

The dimensions of each slice's shell 
(outer surface) must be determined. I 
experimented with several methods, 
but in theend thesimplest onewasthe 
one that worked best. (Usually, if a 
solution istoo complicated, it probably 
wasn't the best solution anyway.) I "x- 
rayed" a character from four different 
angles (side, front, quarter-left, and 
quarter-right), noting the impact time 
for each ray, giving first and last hits 
priority since we know they belong to 
the outer shell, and storing the whole 
thing in four different databases, each 
corresponding to the x-ray orientation. 
Each database was cleaned for loose 
points (points having no immediate 
neighbor). Most internal points are 
removed by looking at the ray data. A 
combination of normal sign logic and 
proximity removes the inner layers, 
such as skin underclothing, and other 
points just under the surface. 
Step 2. Connect the databases. The next 
step is to connect the four databases 
into strings of data for each slice. This 
makes the final maps look a lot better 
since I can safely interpolate between 
points if I know they are connected. 
The routine goes through thefour 
databases recursively, trying to find 
neighboring points one at a time. It 
finds neighboring points by taking 
into consideration criteria such as the 
surface continuity in theform of nor- 
mal, continuous curvature, proximity 
to other points, UV closeness to other 
points, whether points Neon the same 
face, and so on. After this, we have 
neatly connected strings of data. A pic- 
ture of the raw data can be seen i n 
Figure 1. 

Step 3. Apply BONE influences. When we 
first began trying to apply an animated 
skeleton to the model, we didn't feel 
that any of the commercial packages 
would work for us. Neither Bones Pro 
nor Physique provided enough control . 
So Darran and I came up with the con- 
cept of painting bone influences direct- 
ly onto the model (see Figure 2). The 
method is similar to using an airbrush: 
you set the pressure, method of appli- 
cation (average, overwrite, smooth), 
and start "painting" the bone influ- 
ences. It's done in real time, so you can 
play an animation, stop at a frame 
when you see something that needs 
correcting, and just paint on the new 



influences. Using this method, we got 
very good deformation data from the 
start. Si nee the deformation is applied 
directly to the high-resolution model, 
you can regenerate your game model in 
any resolution without having to recre- 
ate all the influences. You can also 
incorporate influences from another 
model if its structure is similar, and just 
clean up the influences later. 
Step 4. Separate the body into suitable 
PIECES. Before the model can be convert- 
ed into the native game format, it is 
necessary to define all body parts. This 
is done using cutplanes. These planes 
cleanly separate the body into various 
parts (arms, legs, torso, and so on), and 
at the same ti me these planes descri be 
the common spaces where patch mesh- 
es must be generated to cover holes 
between body parts that emerge during 
tesselation (more about that shortly). 

Attached to the cutplanes is the defi- 
nition of projection paths. These define 
the projection axis from which the 
patch mesh (think of the patch mesh 
as a tapered cylinder) is generated. The 
number of horizontal and vertical seg- 
ments is defined for each body part, so 
you can change the output resolution 
of the mesh. Figure 3 shows what pro- 
jection paths look like. 
Step 5. Unifying the body parts. At this 
point, the model is ready for unifica- 
tion. This isthestage in which the 
mesh is fitted around the source mate- 
rial, at the appropriate resolution 
specified for each body part. It's as if 
you shrink-wrap cylinders around 
each body part. The strings of raw 
data are then projected onto thefinal 
cylinder, extracted into a texture map, 
and separated so it can be saved sepa- 
rately, and UV coordinates are stored 
for each mesh point. I don't call these 
points "anchor points," because we 
just use them as corner references for 
triangles, not for use in curved-surface 
calculations. Until now, it hasn't been 
feasible to do any spline interpolation 
of the points since hardware perfor- 
mance is still not able to handle the 
resolution that we save the game 
models in (about 10,000 to 16,000 
points per model at full resolution), 
but the resolution is fine enough so 
we can snap to points when wetessel- 
latedown the model. It makes the 
run -time version a lot faster. 
Step 6. Patching holes in the mesh. 
Patching holes in meshes was an aspect 



FIGURE 3. The flexible projection 
paths and their editing. 
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of th e ch aracter an i mati on process th at 
proved to be very difficult to get right. 
We wanted a way to generate a mesh 
that would perfectly stitch up any hole 
that might be created when two cylin- 
ders of different resolution were joined 
together. For instance, to attach an arm 
to a torso, you cut away a round shape 
on the torso that fits the diameter of 
the cylinder representing the arm. A 
hole might appear at any point around 
the cylinder if connecting cylinders 
didn't match up perfectly. 

The problem is especially acute 
when cylinders of different resolu- 
tions are connected; this generates a 
sharp break wherethey are joined. I 
changed the system so that the last 
slice of cylinder being attached (for 
instance, an arm getting attached to a 
torso) wasn't rendered prior to being 
connected. Instead, it was drawn 
directly onto the master cylinder, cre- 
ating much better arm-to-torso transi- 
tions, and especially good leg-to-torso 
transitions. 

Getting the texture mapping correct 
was difficult. Si nee the system uses 
intra-page mapping (to support the 
Playstation and for a more efficient 
video memory), wrapping is not sup- 
ported. And because a character's indi- 



vidual body parts are basically just 
tapered cylinders, it was never neces- 
sary to have wrapping. However, dur- 
ing the process of unifying the various 
body parts into a single character, 
some method of handling wrapping 
had to be devised. To solve the prob- 
lem of properly aligning textures so 
that body parts appeared in alignment, 
I generated a point on the master body 
part, typically thetorso, corresponding 
to a UV coordinate of on the body 
part being attached, allowing textures 
on different parts to match up correct- 
ly. That solved the texture wrapping 
problem. 

Currently, I'm working on a routine 
that sorts out the drawi ng sequence of 
the patch mesh, since a bumpy master 
body part can screw up the projection 
and cause the drawing sequence to 
generate some incorrect points, there- 
by creating holes in the mesh. That can 
become a big mess. 

Step/. Prioritizing points for tessellation. 

Thefinal step is to prioritize the unified 
points. For instance, you want to make 
sure that thetessellator doesn't col- 
I apse th e ti p of a ch aracter' s n ose i n 
favor of some less important surface 
point. As such, you can weigh that 
point so it won't disappear until the 



game turns off the priority routine 
when the model is displayed at low-res- 
olution — in which case the nose 
doesn't matter anymore. Similarly, you 
can prioritize an individual slice of the 
model if it's important to the integrity 
of the model. That way you can make 
sure that the bend slice around the 
el bow i s al ways th ere so th e ben d i s 
kept clean. This process is vital for a 
stable-looking model — as a model 
drops polygons rapidly, there is a 
chance it will remove vital parts. 
Prioritizing si ices and points goes a 
long way towards solving that prob- 
lem. You might assume that prioritiz- 
ing points all over the body would add 
a lot of polygons to your character, but 
in reality thetessellator just works 
around those points. In a wireframe 
view, you can see it just dropping more 
points in adjacent areas. 

Working With the Final Model 

Thefinal model is saved with a sep- 
arate map file for each body part, 
so you can easily load it into Photo- 
shop to fix problems without having to 
do so on the model itself. When the 
run-ti me version of the character sys- 
tem loads a model for the first time, it 
reads in your preferences for the 
model 's appearance, scales the maps to 
fit your restrictions, and quantizes the 
maps if you want indexed color. A 
compressed file of the model is saved at 
this point, so the system doesn't have 
to go through this routine every time 
the model is loaded. 

Figure 4 shows the model in differ- 
ent resolutions. This shot was taken 
before the patch mesh was finalized, so 
there are some discontinuities in the 
hip area, but they are gone in newer 
versions of the tool. 



System Pros and Cons 

The process of creating a final 
model for Messiah is quite 
involved. It gets easier with each revi- 
sion of the tools, but it still takes a bit 
of thought. 

On the upside, we feel confident 
that the models we're creating are 
"future proof" (yeah, yeah — I know, 
nothing really is, but forthesakeof 
argument, let's just let that comment 
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pass). When somebody gets the bright 
idea of upping the average number of 
polygons per character from 800 to 
2000, we won't have to pull out our 
hair. 

Thetessellator is generally a lot bet- 
ter than other solutions at finding the 
right points on a model to eliminate. It 
doesn't create holes between each body 
part because of the patch mesh that 
stitches the holes. 

Having separate body parts makes 
cleanly amputating a limb easy, and 
the model can still be tessellated away 
even after a I imb is severed. 



Multi-resolution mesh (MRM) tech- 
nology as described by Hugues Hoppe 
(a researcher in the Computer Graphics 
Group of M icrosoft Research), has won 
a I o t of accept an ce f o r i t s ease of u se. 1 1 
is a good solution for static objects, but 
if you have highly complex objects, 
modeling them with a limited polygon 
count and mapping restrictions is not 
so easy. Using our system, we can map 
each button on a shirt separately and 
the program determines the final map 
without screwing up the tessellation 
effectiveness. Another drawback to 
MRM is that as soon as you start ani- 



mating M RM objects, you start seeing 
artifacts. These visual artifacts are gen- 
erated by the way M RM -generated 
LODs bend, which in turn is due to the 
"spider web" appearance of the mesh 
around a collapsed vertex. The method 
by which MRM determines which ver- 
tex to collapse is based on the base 
frameof themodel, so an MRM -based 
system wouldn't notice that the arm is 
bent in the animation and might 
remove vertices that might adversely 
affect the integrity of the model in that 
particular pose. 

For static objects, M RM is preferred 
over the method I devised for M essiah, 
since it only changes one vertex at a 
time, so the mesh appears more stable. 
In fact, I made my own demo version 
of M RM for the Game Developers 
Con f eren ce earl i er t h i s year. Our team 
ended up using the routine for a few 
high-resolution objects in Messiah, 
and the technique worked nicely. On 
our system, we found that the tessella- 
tion artifacts get masked somewhat 
due to the fact that everything is 
moving and stretching with the 
animation. 

Another important thing to note 
about our system is that themodel 
can be processed in sections. You only 
need the rotation data from two slices 
at a time in order to render a model 
and make it fit easily in the cache. 
Even next-generation consoles have 
memory restrictions, so it's vital to 
control the temporary memory foot- 
print that calculations require. 
Because our system generates strips 
and fans, the rendering speed of our 
system sees big improvements on any 
hardware. 



Disclaimer 

Th i s arti cl e i s n ot mean t as an 
advertisement for M essiah or the 
character system I've written; I merely 
want to state an alternative to the con- 
ventional approach to generating char- 
acters. The process is being revised 
continuously. It's an on-going taskto 
improve the process of converting 
models from 3D Studio Max to a game- 
optimized format. For now, Darran is 
keeping us busy with neat suggestions 
on how to make his life easier (and in 
doing so, we're swallowing our week- 
ends to make the modifications). ■ 
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As the tools programmer for Messiah, one of the chal 
lenges I faced as I built our in-house development 
tools was deciding how to handle the vast amounts 
of raw data — a model with 400 rings contained 
anywhere from 50,000 to 250,000 points (see Figure 1). Each of 
these points is weighted with up to three bones, which further 
slows the drawing process. Some design ideas were "borrowed" 
from 3D Studio Max, which uses a frame-rate threshold that 
drops the application from shaded mode into wireframe mode to 
increase drawing performance. So in the tool, if the user is rotat- 
ing, panning, or zooming in on the model and the frame rate is 
too low, the program starts to sl<ip points and slices to improve 
the display speed. And as soon an operation is finished, the 
model is redrawn again at the original resolution (see Figures 
5 and 6). 

Unfortunately, this method of boosting performance could not 
be used to paint bone influences onto the points (see Figure 2) — 
each point must be visible in order for the user to see the effect 
that bones have on points as the influences are altered. And as 

Saxs stated in his article, just drawing 

a character model was slow (especial- 
ly when we increased the number of 
slices to 1,000 and we got a couple 
million points). This forced us to rely 
on regional updates when setting the 
influences within the model. Each 
time the model is redrawn, the 2D 
location and information about each 
point was stored in a huge buffer. So 
when the user actually "paints" influ- 
ence with the brush, we perform a 2D 
region test (I actually use standard 
Windows functions for this, which is 
slow), recalculate the position (as the 
influence just changed), and redraw 
the data within this region. The results 
are satisfactory, and it lets users 
change influences within the model in 
real time (using a reasonable amount 
of points). 

The first generation of the charac- 
ter tools had statically defined linear 
projection paths, which meant that if 
a model had body parts that were 
arced, curved, or bent, the generated 
map would be sl<ewed when unifying. 
In other words, it was not a visual 
process at all. When it was time to 
upgrade the tools, the modelers had 
come up with some not-so-humanoid 
characters, which meant linear pro- 
jections were bad. So we added visu- 
al editing features and the ability to 
save spline projection paths. A spline 
projection path is a type of positional l<eyframe sys 
tem: you create position l<eys, move the positions 



B If T a r g 
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FIGURE b.Arota- 
tion is in process so 
detail is reduced on 
tlie model. 




FIGURE 6. Whenthe 
rotation is complete, 
original detail level 
is restored. 



give each position/l<ey a time value. This time value gives resolu- 
tion to the spline, which in turn defines the resolution within the 
cylinder. This feature lets us change the resolution of the body 
part/mesh as we traverse down an arm, for example, and we gen- 
erate higher resolution around the areas of a body part that need 
to bend, as we did in the case of the shoulder area shown in 
Figure 3. 

A Scalable engine Requires Scalable tools The scalability of 
the Messiah engine means more game data for developers to 
worl< with, which in turn means that our game development tools 
must be flexible enough to manipulate all that data. When we 
first started on the game, there was a limit of 400 slices per char- 
acter. However, when that limit was raised, exporting the models 
from 3D Studio to raw rendering data became very slow. We had 
trouble fitting everything into memory, and machines often had 
to fall bacl< and use swap drives to compensate (which is slow). 
When the rendering process ran out of swap space, we really had 
a problem. That's when we heard that Interplay had a network- 
rendering farm consisting of ten DEC Alpha worl<stations. We 
headed over to Interplay's offices to get some information on the 
setup, and afterwards we created a distributed computing ver- 
sion of our raw-data renderer. Using the new distributed render- 
er, 1,000-slice models that used to be rendered overnight could 
be rendered in one and a half hours. 

The communication used for our distributed rendering system 
is very simple. The server saves a command file containing com- 
mands for rendering the slices from the different viewpoints to a 
shared directory and each client exclusively opens this file and 
lool<s for a command that hasn't been tal<en by any other client. 
The server checl<s this file at certain intervals to see if all the 
commands have been rendered. If it finds that all commands 
have been issued but some have not yet completed, it assumes 
that a machine is either very slow or has crashed, and it will reis- 
sue the command to another idle client. 

When I started to write this article, the characters were ren- 
dered with a slice resolution of 1,000, but as I'm wrapping up this 
article, Darran has started to do 1,500 slices. That means that a 
raw binary file coming into our tool is 150MB, and that the prob- 
lem now isn't just with drawing speeds anymore. It is actually 
becoming a problem for the artist to worl< with the model. 
Maldng sure that all the points are influenced and assigned to a 
body part is in itself a challenge. The tools were written with 400 
slices in mind, and worl< beautifully even at around 800 slices, 
but with insane (Darran) resolutions, we need to come up with 
better ways to influence and generate the finished model. More 
sophisticated caching techniques and regional updates are going 
to be used, and that will hopefully enable us to go to even higher 
resolutions. In a year or so we'll probably have 2,000 to 2,500 
slices, and iGHz Pentium Ills with iGB of direct Rambus memory 
at our fingertips. When this happens, we want our tools to be 
able to tal<e advantage of that power. 



around, change tension, continuity and bias, and 



Torgeir Hagland programs his way around the world while conveniently 
dodging the Norwegian army. Write him at torgeir.hagland@powertech.no. 
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Lea i g Li a d 

Centipede 3D 



b tf R i c ft 



a r 



cf RoMAe III 




ast year I was quite dismayed to see that Alfred Hitchcocl<'s 



Psycho was being remade. It's one of my favorite films and I 
couldn't understand why anyone would think it necessary to 



remake it. How could a remake possibly approach the brilliance 



of the original? But then I noticed that Gus Van 



Sant, afilmmaker whose work I admire, was head- 



ing the project, so I thought the remake might have some merit. Still I 
wondered, what could have provoked him to tamper with such a clas- 



sic? The irony is that at the same time I was dubi- 




ous about the prospect of a Psycho remake, I was 
working on a new version of Centipede. The origi- 



nal Centipede, as designed by Ed Logg and Donna 



Bailey for Atari in 1980, is a work of art that I love 



Richard Rouse III was Lead Designer and Al Programmer on Centipede 3D for both the PC and Playstation. 
Before that, he created the games Damage Incorporated and Odyssey - The Legend of Nemesis under the 
Paranoid Productions banner. Since worl<ing at Leaping Lizard Software, Richard has moved on to Surreal 
Software, where he is glad to be working on neither a remake nor a sequel. Feedback and other musings are 
encouraged at paranoid@panix.com. 
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and revere just as much as Psycho. So why didn't I have 
moral reservations about working on its remake? Perhaps 
looking at the Psycho remake from my point of view as a 
Hitchcock enthusiast who isn't a filmmaker, I could only see 
the new version assullying the name of a classic. But work- 
ing as an artist in the computer game medium, I saw that a 
new version of Centipede could be fresh and stimulating, 
using the classic game as a springboard for a completely new 
game playing experience. Without doubt, it would be a 
tremendous challenge to create a game that could live up to 
the reputation of the classic. 

The Task at Hand 

With plans for the PC and Sony Playstation as intended 
platforms, Hasbro Interactive was very clear in 
explaining that they wanted Centipede 3D to be true to the 
spirit of the classic Centipede. Hasbro Interactive had acom- 
mercial hit on its hands with Frogger3D, but atthesame 
time was listening to complaints about the game. It seemed 
that many people enjoyed the first few levels of Frogger 3D 
th e best. 1 1 j ust so h appen ed th at th ese were th e I evel s th at 
most resembled the classic Frogger. Because of this, Hasbro 
Interactive wanted to make sure Centipede 3D was closely tied 
to theoriginal Centipede. 

Leaping Lizard had already spent some time developing 
its outdoor 3D engine, which up until Centipede 3D was 
used exclusively by a flying combat game called Raider. 
Hasbro Interactive saw the technology and thought it ideal 
for their new version of Centipede. A prototype using the 
Raider engine with Centipede game-play components was 
created by Leaping Lizard in record time, and once deliv- 
ered to Hasbro Interactive, the deal was soon signed. Eager 
to work on a project with the challenge of creating a new 
incarnation of Centipede, theteam at Leaping Lizard was 
concerned with exactly the same goal as Hasbro 
Interactive: creating a distinctly modern game that still 
captured the feel of the classic. At the end of 1997 work 
began, using the existing Raider engine but without most 
of the Raider game play in order to make a new version of 
Centipede. 

San Francisco art shop Mondo Media had impressed 
Hasbro Interactive with its excellent work on Interstate '76, 
and it was brought in to do the cut-scenes for the new 
Centipede. Hoping to match the art style of the cut-scenes 
with the in-game art, Hasbro Interactive and Leaping Lizard 
decided Mondo Media would also do some of the animated 
game play art. The core Centipede game play demands that 
there be a large number of monsters and mushrooms on the 
screen at onetime, and as such, a very low polygon count 
was required for all the models. The Raider engine utilized a 
level of detail (LOD) system, which swaps in lower polygon 
versions of models dependi ng on the game's frame-rate and 
a given object's distance from the camera. Mondo Media, 
more experienced with high-polygon work, at first found it 
extremely challenging to stick to the 90-60-30 polygon limi- 
tations for the monsters' LODs. But as the project pro- 
gressed, Mondo Mediaadapted to thepolygon limitations 
and produced some great work, creating more than 20 ani- 
mated character models for the game. 



Designing a Remake 

At Leaping Lizard, work began immediately on the pro- 
ject. Programmers started porting the Raider engine 
over to the Playstation, while designers and artists dove into 
the first world of the game, Weedom. Six levels were pro- 
duced rather quickly, with thefirst two levels attempting to 
mimic the classic game play as much as possible. Hasbro 
Interactive didn't think these levels were close enough to 
theoriginal, however, and by March of 1998 asked that we 
start work on a completely separate "classic game," turning 
what had been a one-game project into a two-game endeav- 
or. As we studied the classic game by endlessly playing our 
authentic, coin-operated Centipede, we not only developed 
th e mock-cl assi c game, but started to reth i n k th e desi gn of 
the modern game as well. Up until this point, the modern 
game levels had not been very reminiscent of theoriginal 
Centipede, and as we studied the classic, we began to see 
why. 

Of thesix original levels that we had designed, only two 
survived without major retrofitting of the landscapes, while 
one was completely overhauled and three were discarded. 
We then spent approximately three months working up 
three new levels, refining and balancing them until they 
were fun and reminiscent of theoriginal Centipede. With 
these first six levels relatively finalized and armed with a bet- 
ter ideaof what was going to work well in Centipede 3D, we 
spec'd out therest of thegameand designed and imple- 

Centipede 3D 



Leaping Lizard Software Inc. 

Gaithersburg, Maryland 

(301) 963-8230 

httn- / /www. lplizard.com 
Mondo Media 

San Francisco, Calif. 

(415) 865-2700 

http://www.mondomed.com 
Real Sports Games, LLC 

Elgin, III. 

(847) 429-4670 

http:/ /www. realsportsgames.com 
Release Date: October 1998 (PC); May 1999 (PSX) 
intended Platform: Windows 95/98, Sony Playstation 
Project Lengtii: 18 months 

Team Size (PC): Seven full-project developers and two part-pro- 
ject developers at Leaping Lizard, working with the artists at 
Mondo Media. 

Team Size (PSX): Three full-project developers and five part- 
project developers at Real Sports Games, with five part-project 
developers at Leaping Lizard, and the artists at Mondo Media. 

Critical Development Hardware: (Beginning of project): 90MHz 
Pentium with 64MB RAM. End of project: 350MHz Pentium II 
with 128MB RAM. 

Critical Development Software (PC): Watcom C++ 11. oa. Opus 
Make, Emacs, 3D Studio Max, Adobe Photoshop, RCS source 
control. 

Critical Development Software (PSX): Metro we rks 
CodeWarrior for Playstation, Opus Make, Debabelizer, 
StarTeam source control. 
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merited 23 more levels in only three 
months. By working initially on only a 
few levels until they were actually 
enjoyable to play, we were infinitely 
more prepared to design the remainder 
of the game, and hence had to do 
almost no reworking for the rest of the 
project. 

The Playstation Version 

Around April, both Leaping Lizard 
and Hasbro Interactive became 
concerned that Leaping Lizard wasn't 
going to be able to getthePSX version 
of the game running by the holiday 
season deadline. This was largely 
becauseof difficulty finding an avail- 
able PSX specialist, and a number of 
PSX programmers that Leaping Lizard 
had hoped to hire had backed out at 
the last minute. As such, both Leaping 
Lizard and Hasbro Interactive thought 
it would be best to bring in another 
team to handle the PSX conversion, 
preferably someone who already had a 
suitable engine running on the PSX. 
That team turned out to be Real Sports 
Games of Elgin, III. Real Sports Games 
had a very nice looking Playstation 
engine up and running itsthen-in- 
development Jeff Gordon XS Racing 
title, and thought they would be able 
to get the conversion donefor the all- 
important Christmas deadline. The 
deal was fin all zed at the 1998 E3 Expo, 
and they started work on assessing and 
porting thetitle immediately. 

Real Sports Games was given an 
extremely challenging goal: porting a 
game which was not yet complete. This 
made it more difficult to fully assess 
the scope of the project and to see how 
it would fit within the constraints of 
the PSX. Further complicating matters 
was the fact that, in order to get the 



PC screenshot taken of first 
world, Weedom. 




game to work with 
their engine, they felt 
they had to rewrite 
large sections of the 
PC game's code from 
scratch. Though the 
decision was made to 
use the exact same 
level files as the PC 
version, the project 
became less of a 
straight conversion 
and more of a rework- 
ing of the PC version 
of Centipede 3D. Real 
Sports Games ended 
up neither doing truly 
concurrent develop- 
ment with the PC 
team, nor porting a 
completed game. 

Following comple- 
tion of the PC version 
in October, I was 
flown out to Elgin to 
work with the Real 
Sports Games staff on 
wrapping up the con- 
version and to make 
sure all of the correct 
design and game-play 
el em en t s were f u n c- 
tioning correctly. My 
stay was initially to be 
for two weeks. Once 
there, however, I 

observed how many of the game-play 
elements had yet to be implemented, 
and I began noticing how different sys- 
tems in the game, though they might 
work on earlier levels, were not going 
to be adequate in later levels. My stay 
in Elgin stretched to three months as I 
started working on the coding of the 
game, and got all of the game-play ele- 
ments working correctly. During this 
time, other members of Leaping Lizard 




PC (top) and PSX (bottom) 
screenshots taken of the 
second world, Frostonia. 



were flown out to help 
rJ finish the project, in clud- 
ing programmers Chris 
Green and Gary Skinner, 
artist Jane Miller, and 
project manager Elaine 
Albers. In December, the 
game entered beta, where 
it stayed for four months, 
going through a particu- 
larly long and arduous 
quality assurance process. 
Fortunately, after 
December 1 wasableto 
work remotely on bug 
fixes and to fine-tune 
game play using the 
excellent StarTeam source 
control system, which 
worked seamlessly over 
the Internet. 

Working on Centipede 
3D was at once an 
extremely gratifying, yet 
terribly confounding 
experience. The game's 
design seems to have 
worked out particularly 
well, with play that 
instantly reminds people 
of the original game. 
Getting that design 
implemented on the PC 
side was a challenging, 
yet rewarding experi- 
ence. But then making 
that design function on a system sig- 
nificantly less powerful than the PC 
proved mind-numbingly difficult and 
unendingly frustrating. The entire 
team was disappointed when the 
product didn't make its Christmas 
ship date. Looking back on the whole 
project, there are somethings that 
worked out gloriously well and other 
things that only cause us to hide our 
heads in shame. 




The evolution of a classic: From left, the original Centipede from 1981; how the mock-classic game looked at one point during 
development; how the mock-classic appeared in the PC version; and the completely 2D incarnation of the classic game, found 
in Playstation Centipede 3D. 
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What Went Right 



IThe scripting 
# LANGUAGE. Centipede 
3D made heavy use of 
Leaping Lizard Software's 
proprietary scripting lan- 
guage. Created to allow 
easy implementation of 
game-world objects with 
unique behaviors, the lan- 
guage was in part intended 
to allow non-programmers 
to make modifications to 
the game. But, as it turned 
out, th i s wasn 't real I y th e 
case; John Marzulli (a pro- 
gramming intern) and I did 
the vast majority of the 
scri pti n g work i n th e game, 
and were able to do so only 
because of our program- 
ming backgrounds. Indeed, 
we pushed the scripting 
language far beyond what 
1 ts creato r, C h r i s G reen , 
ever imagined it would be 
used for. The support for "#define" and 
"#include" Style functionality made the 
scri pts q u i te versat i I e an d powerf u I . 
Except for the Centipede's behavior, all 
enemy A! in the game was implement- 
ed using the scripting language. 
Because the scri pts are i nterpreted at 
run time, no recompiling was required 
when a script was changed, and only 
the scripts used on a particular level 
were even loaded into memory. 

ForthePSX version, however. Real 
Sports Games decided early on that a 
run-time interpreted scripting system 
was simply not going to work. In addi- 
tion, floating-point numbers were used 
heavily throughout the scri pts, and the 
PSX is notoriously slow at floating- 
point emulation. Some effort was put 
into hand-converting scripts into C 
code. But once the sheer number of 
scri pts used in the game was fully 
understood, team members began to 
real i ze t h at perh aps th ere were si m p I y 
too many scri pts to convert in the time 
available. 

Chris Green came up with the idea 
of writing a converter that would take 
the scripts and convert them into C++ 
code, substituting fixed-point values 
for floating-point numbers in the 
process. The scri pts, by thei r very 
nature, were completely platform- 
independent and lent themselves to 




PC screenshot taken of third 
world, Infernium. 



PC screenshot taken of the 
fourth world, Enigma. 



direct porting. Chris's script converter 
worked out extremely well, and its suc- 
cess meant that once we had a one-to- 
one correspondence between functions 
called by the scripts and functions 
aval I abl e i n th e PSX versi on , we 
instantly had all monster Al and other 
world-object behaviors converted as 
well. Asa bonus, nearly all of thecon- 
verted scripts were bug-free, si nee they 
had already been through a fairly rigor- 
ous testing cycleon the PC. Due to 
their strange syntax and frequent use 
of nested function calls, CodeWarrior 
took hours to compile the converted 
scripts and it generated a fairly large 
amount of code. But due to the PSX 
version's use of application chaining, 
only the scri pts used on a given level 
were actually included in the exe- 
cutable, thereby allowing the game to 
fit in memory despite these inordinate- 
ly large compiled scripts. 

2 Studying the classic game. 
# In creating the mock-classic 
game that was included with Centipede 
3D, we had to spend a lot of time 
studying in fine detail the behavior 
and balance of all the elements in the 
original Centipede. We spent many 
hours in front of our authentic 1981 
Centipede coin -operated game analyz- 
ing the game play. We came to under- 
stand the vital game-balance depen- 



dencies between the Flea, 
Spider, Centipede, and the 
mushrooms. Remove any 
one of them or alter how 
they work or when they 
appear, and the game falls 
apart. 

Though the classic recre- 
ation game included with 
Centipede 3D didn't liveup 
to anyone's hopes, study- 
ing the exact play mechan- 
ics of the original 
Centipede did help us 
immeasurably in designing 
the modern game. 
Understanding the classic 
game-play mechanisms was 
key to recreati ng the feel of 
the original game and 
allowed us to mimic exactly 
the movement patterns of 
the core monsters. Though 
the renderings of the 
insects in the new game are 
nothing I ike the classic, 
when players watch the 
monsters' mimicked movement pat- 
terns in the new game, they see a visual 
echo of the classic, thereby instantly 
reminding them of it visually. In the 
end, much of the game play that suc- 
ceeds in Centipede 3D isthedirect 
result of studying the game design 
work that Ed Logg did nearly two 
decades ago. 

S Correct PSX decisions. I n the 
# process of developing the PSX 
conversion of Centipede 3D, several 
seemingly insurmountable obstacles 
presented themselves. Fortunately, at 
th ese j u n ctu res th e program mers were 
able to make the right decisions, 
which, had they been incorrect, could 
have doomed the project completely. 
Looking back now it's easy to see that 
the choices made were the only ones 
that could have worked, but when the 
decisions were made the programmers 
were relying primarily on intuition and 
gut instinct. 

One of the earliest of these crucial 
deci si on s was to wri te tool s wh i ch 
would convert the PC level and model 
files into PSX-usableform, primarily by 
removing all of the floating-point 
numerical data. Real Sports Games had 
bandied about the idea that perhaps 
new levels should be crafted for the 
Playstation version. But Real Sports 
Games decided that there was nothing 
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The Wee Miner from the Infernium levels, sketch and 
finished model. 



















The Wasp boss insect from the Infernium levels, 
sl<etch and finished model. 



that the PC levels did from a design 
standpoint that couldn't be accom- 
plished on the PSX as well, and since 
these were well balanced, thoroughly 
tested levels it was the right decision to 
use them in the console version instead 
of discarding them. 

As the PSX development proceeded 
an d t h e CO n verted scr i pt fi I es were 
added to the game, it soon became 
obvious that there was simply not 
going to beany way to fit all of the 
code into the two megabytes of main 
RAM found in the PSX. Once we had 
acknowledged that something had to 
be done, PSX project lead Brian Rice 
decided that application chaining was 
the only way to get the game to work, 
arguing down nay-sayers and cynics 
along the way. Asa result of Brian's 
quick and authoritative decision mak- 
ing, the game has not just one, but 11 
separate executables, with different 
applications able to quit and run each 
other as the player moves from menus 
to game play, or from level to level in 
the game. By separating out code that 
was used only in certain sections of the 
game and removing it from the exe- 
cutables (something which Code- 
W arri or's dead-code stri ppi n g capabi I i - 
ties simplified greatly), each of the 11 



applications was 
squeezed into the two 
megabytes aval I abl e. 
Without this application 
chaining, there is simply 
no way the game would 
ever have worked on the 
Playstation. 

4 Separate "Classic" 
# AND "Modern" 
Versions of the Game. 
Centipede 3D started out 
to be one game but 
turned into two along 
the way. Hasbro 
Interactive, having 
learned that what people 
liked best in Frogger3D 
were elements that most 
resembled the original, 
wanted Centipede 3D 
players to have a game 
very much I ike the one 
they remembered from 
theearly 1980s. Initially, 
the designers considered 
including all of the fea- 
tures that players would 
expect from a new con- 
sole-style game— level-based play, 
exploration, power-ups, and so forth — 
in someof the levels, while having 
other levels which matched the classic 
game play exactly. The two styles of 
game play were to alternate through- 
out the levels, thus giving players both 
new and old style games in one. 

But in attempting to mix the two 
modes of game play, neither was going 
to work out very well, and players 
would be confused and frustrated by 
the constantly shifting styles. The 
wholeteam soon realized that having 
completely separate games was the way 
to go. One game would feature mod- 
ern-style game play that would be rem- 
iniscent, though quite different from, 
the original Centipede, and this style 
would be consistent through the whole 
experience. The other "classic" game 
would give the user game play identical 
to that found in the original game, 
though presented in a new isometric 
3D view. For the PSX version, the clas- 
sic game was taken one step further, 
using 2D graphics and sounds identical 
to the original game's. In this way, the 
two different styles of game play could 
exist separately, with players who 
wanted precise Centipede game play 
able to get that, while the modern 



game was allowed to flourish as a sepa- 
rate entity, no longer tied down to the 
constraints of the original game. 

5 Designer multi-tasking. There 
# were two designers on 
Centipede 3D, and both of us were 
actively involved in the implementa- 
tion of our design ideas. I served as 
both designer and programmer on the 
proj ect, wh i I e M ark Bu 1 1 ock was both 
designer and artist. Together we 
worked out all the game's design issues 
and made all the levels found in the 
game. 

By being intimately involved with 
both the programming and art in addi- 
tion to our design responsibilities, we 
were able to come up with design ideas 
and then implement them almost 
instantly. Mark could throw together a 
concept sketch, model the piece, and 
then I could make the game element 
actually function in thegame world. 
Instead of having to explain our vision 
to someone else, we were able to just 
"make it so" and see how well it 
worked in thegame in a very short 
time. Though I have nothing against 
designers who are neither programmers 
nor artists, our ability to multi-task 
allowed us to achieve a certain Zen-like 
state during the game's creation, which 
let us crank out the game's levels in 
record time. Though we delegated art 
and programming responsibilities to 
other members of the team, because we 
had full understanding of the program- 
ming and art limitations of the project, 
we were able to avoid impractical or 
unaccomplishable design ideas, and 
instead focus on what we knew we 
could get to work in the limited 
amount of time we had to make the 
Christmas deadline. 



What Went Wrong 



1 Classic game should have been 
# EMULATED. Despite our best 
efforts, the classic game that comes 
with Centipede 3D is not precisely the 
game that Ed Logg created. There are 
differences which any hard-core 
Centipede fan will notice, and both the 
PC and PSX mock-classic Centipede 
games don't quite feel right. The new 
3D visuals in the PC classic game don't 
really do anything to make the game 
any more fun, and even though the 
PSX goes so far as to look and sound 
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The Cockroach insect from the Evile levels, sketch and fin- 
ished model. 



exactly liketheoriginal Centipede, it 
still just isn't the classic. 

Though many software companies 
are wary of emulators and the income 
they may be "stealing," here is an 
instance where one could have worked 
wonders. Many such emulators exist 
on the PC side, and one had even 
appeared for the PSX, as used in 
Midway's Arcade's Greatest Hits: The 
Atari Collection. Instead of the great 
quantity of man-hours spent trying to 
recreate the classic behaviors and game 
play, the same amount of time could 
have been invested in writing our own 
emulator that would have permitted us 
to include theauthentic Centipede 
with Centipede 3D. Perhaps if we had 
realized early on that we were going to 
end up with two completely separate 
games, instead of the single game we 
originally designed, we might have 
seen that emulation was the best solu- 
tion to the challenges that lay ahead. 
No onefully realized how much work 
would go in to recreating such a simple 
game precisely and I firmly believe no 
amount of work on the mock-classic 
would have resulted in a game that was 
as good astheoriginal ROM. When 
attempting to pay homage to the bril- 
liance of a classic game, nothing does 
as well as presenting the actual game 
itself, functioning exactly as it did 
when it was released. 

2 Game Was Too Hard. From the 
# beginning. Centipede 3D was 
supposed to be a mass-market title, a 
game anyone could pick up and play 
fairly well from the start. Definitely not 
aiming at the hard-core game player, 
Hasbro Interactive had seen wild suc- 
cess with its mass-market Frogger 3D 
and wanted Centipede 3D to appeal to 
exactly the same consumers. It was said 
that even Frogger 3D was too hard in 
places, and if we could make Centipede 
3D easier, we'd beheading in the right 
direction. 



But it was not to be. I n the end. 
Centipede 3D turned out to be a far 
more challenging game than Frogger 
3D. As a designer on the project and 
th e on e I argel y respon si bl e f or bal an c- 
ing the levels from a game-play per- 
spective, I take full responsibility for 
this shortcoming. The usual problems 
that lead to excessive difficulty can be 
found to be true here. First of all, none 
of the people playi ng the game during 
its development — designers, program- 
mers, producers, and testers — could 
really be considered members of the 
computer game mass-market. We were 
all adept at a variety of games, includ- 
ing many distinctly hardcore titles, and 
as such, we were far 
more experienced 
than the target 
audience. The 
members of the 
team who were not 
such avid game 
players were not 
encouraged to play 
the game as much 
as they should 
have been, and 
consequently, they 
didn't voice com- 
plaints about its 
difficulty. 

There were many 
complaints early 
on in the game's 
development that 
it was too difficult. 
Accordingly, I did 
some work to reme- 
dy this, and by that 
timethecom- 
plaintshad disap- 
peared. I concluded 
erroneously that 
the tweaks I had 
performed had 
fixed the difficulty 
problems, and 



hence stopped worrying about them. 
What had really happened, I suspect, 
was that I made the game just slightly 
easier, and that in the time it took me 
to accomplish that, the people who 
had been complaining about the 
game's difficulty had gotten a lot better 
at it, and therefore stopped complain- 
ing. The solution to the challenge of 
testing the difficulty of a mass-market 
game, it seems, is always to test the 
product on a "newbie," someone who 
has never played the game before. 
Only then will one know for sure if the 
game is getting easier or harder. 

Actually, I think Centipede 3D isjust 
about as hard astheoriginal Centipede, 
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The Shooter — the ship the player controls through the game — has four different 
LODs. Since the default camera view is so far from the ship, most of the time play- 
ers probably see LOD number three or four. Notice that Wally, the character in the 
Shooter, has turned into a plane by LOD four. 



perhaps even a bit easier. A game on 
the classic version only lasts a few min- 
utes for the majority of players, and was 
designed as such to maintain a steady 
flow of quarters. Though Centipede 3D 
was aimed at the home market from the 
start and as such should have provided 
a much longer average play experience 
for users, I I ike to think it was the 
game's emphasis on being I ike the clas- 
sic that made it so hard. 

S Extended Crunch Schedule 
# Prevented Long-Term Planning. 
When I started working on the PSX 
version of Centipede 3D in October of 
1998, everyone involved with the pro- 
ject was estimating that the conversion 
had about two weeks remaining. Two 
weeks later, after I had spec'd out all of 
the game-play elements that were still 
missing from the PSX version, it was 
decided again that there were two 
weeks left to get all of those game ele- 
ments working. This pattern continued 
as the project extended on for another 
six months. No one involved fully real- 
ized the scope of getting Centipede 3D 
to function on the PSX. 

From a business standpoint, the pro- 
ject needed to be done in two weeks, 
but unfortunately, from a program- 
ming standpoint, there was no way 
this could happen. Being in perpetual 
crunch-mode and constantly thinking 
thegamewas nearly finished, program- 
mers were i n cl i n ed to h ack system s 
together in the quickest way possible, 
not fully considering all the problems 
that might result from such hastily 
constructed code. In the end, much of 
the rushed code had to be rewritten to 
fix all the bugs associated with it, 
which further extended the develop- 
ment time. The ongoing feeling that 
thegamewas nearly finished, but then 
not having it work out that way was 
also horrible for morale. If anyone had 
fully realized how much time was left 
on the project, the programmers could 
have taken the time to port systems 
correctly, look at the project wholisti- 
cally, and structure their work better. 
In theend, coming up with a more 
realistic schedule might have shaved a 
month or two offthetotal project time 
and resulted in a less stressful experi- 
ence for the team. 

4 Incompletely Ported Systems. I n 
# porting the game over to the 
PSX, some of the key systems in the PC 
game were initially rewritten without 



fully understanding or considering all 
thefunctionality they had to include. 
In part becauseof the intense schedule 
we were working under, programmers 
would often look at how a given game 
system worked in a few situations and 
then make sure their implementation 
of the mechanism would perform all 
that they had observed, instead of 
going over the PC code and converting 
it line by line. Unfortunately, usually 
only the early levels were considered 
during this observation stage and it 
would turn out that on later levels the 
system had to do a number of addi- 
tional things that its ported incarna- 
tion could not. In the worst-case sce- 
nario, the only way to get that system 
to include thisadditional functionality 
was to rewrite it from scratch . 

One example of this problem was 
water. Centipede 3D for the PC uses a 
massive textured plane for its water, 
which is drawn before any terrain 
geometry is rendered instead of clear- 
ing the screen, and which could there- 
by extend to infinity past the edge of 
the game world. This caused us to 
design many of the game's levels as 
islands set in the middle of infinite 
seas. The water also had the advantage 
that it could trivially be made to rise to 
any elevation, potentially flooding pre- 
vious areas or th e en ti re I evel , a feature 
we exploited when designing the 
game. Due to Z-buffer limitations on 
the PSX, Real Sports Games realized 
early on that it was impossible to 
implement water in the same manner 
in the con sole version. The developers 
at Real Sports went out of their way to 
create a water system for the PSX ver- 
sion that in some ways looked far bet- 
ter than the PC version's water. Instead 
of being aflat plane, its water was com- 
posed of triangles which undulated up 
and down in beautiful, wave-like for- 
mations. This looked great on the early 
levelsthat had relatively small quanti- 
ties of water. Unfortunately, the more 



space on the level the water filled, the 
more memory it took up due to all the 
vertex data. The levelsthat were tight- 
est on memory were ones that featured 
a lot of water, and a lot of time was 
spent pruning other objects from these 
levels in order to prevent them from 
overflowing the PSX's memory. 
Furthermore, the PSX version's water, 
due to its memory-intensive nature, 
could not extend forever as the PC ver- 
sion's water did, and consequently, the 
island levels looked ugly. If from the 
start the PC game's water usage had 
been looked at on all the levels instead 
of just the first few, it is possible that a 
completely different implementation 
of the water on the PSX could have 
been undertaken, one which would 
have included all the necessary func- 
tionality. 

5 No Updated Design Document. In 
• a project such as Centipede 3D, 
where two separate teams were work- 
ing on two separate code bases on 
games that were supposed to share a 
design, a living, up-to-the-minute 
design document is an absolute neces- 
sity. Unfortunately, beyond outlines 
written early in the project, most of the 




The Centipede, Flea, Spider, and 
Scorpion each appear throughout the 
game, with different texture treat- 
ments for each of the five worlds. 
This helped give each world its own 
unique lool<. Here is the Scorpion in 
its five different incarnations. 
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design was understood by the two peo- 
ple who had to make it work — M ark 
Bullock and myself — and not by any- 
one else. Indeed, for the PC version it 
wasn't necessary for anyone else to 
understand all the intricacies of the 
design, since we were working as such 
a close-knit team, and when anyone 
had questions about the desired func- 
tionality of a particular piece of code or 
art, they could come to us and ask. 

Most of the game play and all of the 
levelsfor Centipede 3D were created 
between March and September. Given 
that intense crunch schedule to get the 
PC version out for Christmas, there 
really wasn't any time for either Mark 
or me to maintain a complete and up- 
to-date design document, nor did any- 
one ever suggest we do so. 
Unfortunately, with a PSX develop- 
ment team a thousand miles away, a 
document that completely spec'd out 
everything that happened in the game 
was vi tal I y i m po rtan t f o r keep i n g t h e 
two teams in sync. Without such a doc- 
ument, the PSX team didn't fully 
understand all of the different bits of 
game play and A! found in the PC ver- 



sion, nor did they fully 
comprehend the scope of 
some systems. 

How Does It Feel? 



I eedlessto say, every- 
one who worked on 
Centipede 3D grew stronger 
as game developers from 
the experience. I know that 
I've come to understand a 
lot about balancing game 
difficulty and the impor- 
tance of an up-to-date 
design document in a pro- 
ject of this size. Leaping 
Lizard Software has since 
moved all its console devel- 
opment in-house, and its 
current project has simulta- 
neous development on 
multiple platforms working 
painlessly. 

Remakes th emsel ves are tri cky propo- 
sitions, especially of much-loved pieces 
of art. Often it means that people are 
expecting you to screw it up and to 



have defiled a clas- 
sic in the process. 
But when remakes 
work out well, they 
can take the 
strength of the orig- 
inal work and add 
to it their own inter- 
pretation. Think of 
thejimi Hendrix 
Experience covering 
"Like a Rolling 
Stone"or "Day 
Tripper;" great 
songs before, great 
songs after (though 
very different in 
each rendition). 
Whether or not 
Centipede 3D suc- 
ceeded in its aspira- 
tions to rework a 
classic into a fun, 
new experience is 
not something I can judge fairly from 
my perspective, though its develop- 
ment was a very stimulating creative 
endeavor. But of course, I never did see 
the new Psycho. ■ 




PC (top) and PSX (bottom) 
screenshots from the fifth 
world, Evile. 
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Smart Toys: 

Not Just Kids' Stuff 





mart toys are hot. Very hot. Last February's 
American International Toy Fair was flooded 
with new smart toys of all kinds: plush Tele- 
tubby Acti mates from Microsoft, full play sets 



from Zowie Intertainment, thePlay- 
skool key-top toy, products such as 
N erf Jr. Foam Fighters from Hasbro, 
Mattel's Barbie Digital Camera, and 
more challenging products for older 
kids, such as Intel's PlayX3 M icro- 
scopeand Lego's M indstorms Robotics 
Invention System. 

All of th ese toys made i t to E3 as wel I , 
but the game industry was more 
focused on poly-pushing to deliver the 
latest in muscle-popping heroes and 
big-breasted she-shooters. Color me 
sensitive: I develop kids' software. 
Color me hypersensitive: most game 
developers view smart toy development 
asadull undertaking — just another 
input device, I hear, or, how hard is it just 
to get thedamned thing to play a bunch of 
audiofiles? But as someone developing 
them, I can tell you that smart toys 
pose in credible challenges and rewards 
for game developers. 

First, whatever adults think of that 
purple mush monster, Microsoft's 
Barney Acti mate sold hundreds of thou- 
sands of units in its first year and gener- 
ated $50 million in revenues. Second, 
the companies working in thefield are 
advancing technologies such as voice 
recognition, infrared, and much more 
complex peripherals — which provide 
new ways for all audiences, not just 
kids, to interact with games. Third, cre- 
ating new ways for users to interact with 
computers and each other poses truly 
tasty challenges for developers — partic- 



ularly when those users are incredibly 
complex small creatures called children 
Designing kids' products is both mad 
den ing and delightful: children have 
less manual dexteri- 
ty, may not be 1 ^ 
abl e to read, \ySJ 

) 




with no defined endpoint; it stops 
whenever the child has had enough. 

Applications written for smart toys 
are not too different from traditional 
computer games that we're all comfort- 
able with: logical units of code provide 
rule sets that classify user input options 
and specify potential outcomes. As 
game developers, we're very good at this 
part. In order to find that game/toy bal- 
ance, though, we have to crank our 
thinking around to accommodate the 
toy part of the equation. 
Play patterns. A toy is not j ust an 



enjoy a thor- 
oughly 
nonsensi- 
cal humor, 
and have 
limited 
attention 
spans, yet possess 
a bizarre ability to 
obsess for hours 
over some detail that may 
be totally incomprehensi- 
ble to adults. The challenge 
(read: fun) is delicately bal- 
ancing "game" and "toy" to 
create a sati sfyi ng user expe- 
ri en ce th at i s greater th an 
the sum of its parts. 

I call it a balancing act 
because "game" and "toy" are in fact 
contradictory concepts: a game is an 
activity, governed by a collection of 
rules and logic, while a toy is a physi- 
cal object around or through which 
play occurs. Game play is basically a 
linear progression through a finite set 
of interactions to a logical conclusion, 
at which point a player "wins" or 
"loses." Play with toys, on the other 
hand, is free-form and exploratory. 



Seonaidh Davenport is the Executive Producer for Consumer Titles at Human Code, 
an Austin-based developer currently producing Redbeard's Pirate Quest and Ellie's 
Enchanted Garden for Zowie Intertainment. Shethinks she's in pretty good touch 
with her inner child. Contact her at seonaidh@humancode.com. 



alternate input device. The goal of 
designers isto keep thechild feel- 
ing comfortable and in control, 
while providing a rich, sat- 
isfying, and pleasantly 
challenging play experi- 
ence. Activities must first 
and foremost be fun, requir- 
ing minimal instruction. 
The program must grace- 
ful ly accommodate a 
complex pattern of 
user attention as it 
shifts between the 
screen and the toy. (In 
our experience, 
attention is split 
about 50-50 between 
the toy and the screen 

illustration by Jackie Urbanovic Wh en th e tOy 1 S COn - 

nected to the computer.) Finally, the 
child must have the latitude to explore: 
tying the child to a strict linear path 
and relying on error messages to keep 
them thereonly leads to frustration and 
the destruction of innocent plastic. 

The program, in short, must be even 
more respon si ve to th e su btl eti es of user 
interaction than is required in regular 
game play development. Any activity 
must be almost infinitely interruptible, 
because you can't dictate what thechild 
should be doing next. You can't tell 
them they're wrong, but you had better 
not lose them. This introduces substan- 
tial complexities in thedesign of game 

continued on page 71 
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continued from page 72 

or activity structure, state tables, dialog 
trees, asset loading strategies, error 
recovery, and so on. 
Physical objects. As wel I as bei ng con- 
scious of play patterns, developers 
should get cozy with industrial design. 
Aside from logistical issues, such as how 
the connection works or where the toy 
can live in relation to the computer, the 
tacti I e experi en ce must be sati sfy i n g f or 
thechild, with the input and feedback 
loop extending beyond what's happen- 
ing on-screen into the physical toy. 
Physical toy design and software design 
must inform one another, so the toy 



and software representations should be 
designed in a recursive cycle. Keep in 
m i n d th at th e man uf actu ri n g cost of 
the toy will frequently drive the func- 
tionality of the software. 

The physical toy radically affects soft- 
ware production and testing processes 
as wel I. Prototypes are expensive to pro- 
duce (making them few in number), 
tend to be fragile, and don't work the 
same way the manufactured un it wi 1 1 . 

So how do you deal with all this 
when designing and developing? How 
do you know you're on the right track? 
Early, frequent, and ongoing kid test- 
ing isabsolutely critical. Developers 



must be unflinching in receiving feed- 
back, and rigorous in its application to 
both the physical and software product 
design. Be patient and allow time for 
when your fundamental design 
assumptions are blown away by some 
tow-headed little darling. 

I've only skimmed the surface of the 
major issues our teams have dealt with 
in smart toy development. While the 
range of products on the market prove 
that there isn't one right formula for 
the mix of toy and traditional CD-ROM 
game development, we're having 
tremendous fun experimenting with 
themix. ■ 
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